S
slacroixak
Guest
I missed this discussion last month that is pretty close to the recent "How to catch this untrapable STOP" one. I am now hitting this (documented) limitation while restructuring some classical UI .w procedures with structured error handling (BLOCK-LEVEL ON ERROR ... all along the way). My main concern is to catch the CallStack Trace of an unexpected error that occurs somewhere deep in new OO ABL methods, so we can investigate it. The only work around I can manage to achieve is a single line include file to replace the "END" statement of a UI trigger. (single line to not affect line numbers in the debugger) /* END_UITriggerCatchError.i */ CATCH ple AS Progress.Lang.Error: Tools:ShowException(ple). END CATCH. END. Like others said in this discussion, I really wish we could overcome this limitation and educate the WAIT-FOR to let an error object be caught by a CATCH in its block. By the way, I have no problem to catch ABL error objects when an error is thrown by an ABL method invoked by some .Net WPF controls UI triggers... Now, if it not possible to educate the WAIT-FOR this way (I have to confess I fall in the category of people with the "common misconception" issue), then I do not see why the ABL could not be a first un-common language providing the ability to catch an error message and its call-stack (when -errorstack is eabled, of course) and pass it as a kind fo Progress.Lang.whateverError to some custom error handling code. Why being a follower when we could enjoy being a leader? (at least is a little space...) Is there any logged Enhancement Request for such a feature, or should I log it one day?
Continue reading...
Continue reading...