Is there a trick in sing the UNDO, THROW statement? It seems to be a hit or miss. I have already added "ROUTINE-LEVEL ON ERROR UNDO, THROW" to my CLS files but still the UNDO, THROW will just hang the application instead of displaying the standard .NET messagebox for unhandled exception.
I'm out of the office until Tuesday May 22nd but will respond to your message as soon as possible on my return.
If you have an urgent issue in the meantime please contact our Support team using firstname.lastname@example.org , or the contact numbers below.
Border Merchant Systems
Tel: 01600 715139
Fax: 01600 716971
The information contained in this e-mail is confidential and privileged; if you are not the intended recipient please notify the sender and delete the message.
Any views or opinions presented are solely those of the author.
not that I play with the .Net gui too much but afraid there is no default 'unhandled exception' message but the default ABL error handling, in that case the error/exception is probably finally catch in an "undo, retry" block which put the whole thing in an endless loop.
We don't use UNDO, RETRY.
The purpose of UNDO THROW, is to do the undo and then pass control up along with the error up to the caller. The caller needs to handle the error - in your case display the error. It is like putting NO-ERROR on the statement in that is stops any system processing of the error. If you do not want to handle the error yourself, remove the THROW and you should see the error message pop up automatically.
I'm not so sure I understand what you mean by remove THROW to display the message automatically.
Basically, I just want to stop the program execution if I THROW an exception (mostly custom exceptions), if it's not handled, the unhandled exception message box should show.
So there is some interesting behaviour here (I tested in OE11 but seem to remember this being the same in 10.2B). Run the attached Form1 for example, using the code below.
def var oForm as Form1.
oForm = new Form1().
catch oError as Progress.Lang.Error : message ' after wait-for' oError:GetMessage(1) view-as alert-box.end catch.
There are4 buttons on the form, corresponding to 4 states: caught and uncaught, and P.L.Error and P.L.AppError. Each button has their own event handler. The uncaught buttons simply raise error and let the form deal with them (it uses ROUTINE-LEVEL); the caught buttons have a CATCH statement, in which they message the error. They also UNDO, THROW the caught error.
The difference in behaviour comes when the errors have 'real' error messages (ie numbered, not simply using ReturnValue). I call those 'error' and the others 'apperror'. The 'apperror' messages are simply swallowed by either the AVM or the CLR or something inbetween. The 'error' errors raise a message, but this cannot be caught anywhere. That CATCH after the WAIT-FOR does nothing.
The text below comes from the GUI for .NET Programming guide, in the OE11 doc set (~pg98). Because of this I have a standard to have a catch in all my event handlers, so that I can intercept the errors before they get handed off to .NET and disappear into the gloom default display device
Raising errors from ABL handlers for .NET eventsWhen a .NET event is published to which you have subscribed ABL handlers (see the “Handling .NET events” section on page 82), if an error condition is raised from an ABL handler for the .NET event, the AVM does not throw an Exception to the .NET Common Language Runtime (CLR), but displays a message to the default output device and processing continues as if no error has occurred. Thus, if any handlers for the event have not yet run when a handler raises an error, all remaining handlers continue to run.
Edit: I should note that the OE11 doc is vastly better than the 10.2A doc in this regard.
HTH at least a little,
So the trick is, if using AppError, to supply a number?
Yes. That's a huge design failure with the AppError constructors: The usage of the optional second integer parameter changes the meaning of the first character parameter...
I guess every ABL developer dealing with the structured error handling must have gone through that experience once or twice ...
We typically always use ,0 for the optional numeric parameter.
Also syntax wise, which should we use?
ERROR new Progress.Lang.AppError('Whoops!', 1).
UNDO, THROW new Progress.Lang.AppError('Whoops!', 1).
What is the difference by the way?
seconded. Always use a number at the end, even if it's 0
Looks like the actual message string and number of messages are not being passed to the CATCH if using AppError with no second parameter. This seems like a bug.
This seems like a bug.
The bug wqas the spec, not the implementation
NEW AppError ("Hello World") .
--> AppError with NO message but a ReturnValue set, equally to RETURN ERROR "Hello World" .
NEW AppError ("Hello World", 0) .
--> AppError with one message and NO ReturnValue set.
I assume in the first case, that was the RETURN ERROR Syntax. Right?
UNDO, THROW throws to the next block.
RETURN ERROR throws to the caller of the current routine.
Not so sure why AppError is muddied up this way if RETURN ERROR "some string" is still functional.