UNDO, THROW statement is hit or miss - Forum - OpenEdge Development - Progress Community

UNDO, THROW statement is hit or miss

 Forum

UNDO, THROW statement is hit or miss

  • 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 support@bordermerchantsystems.co.uk , or the contact numbers below.

    Kind regards

    Gareth Edwards

    Border Merchant Systems

    www.bordermerchantsystems.co.uk

    Merchant House

    Whitecross Street

    Monmouth

    NP25 3BY

    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.

    -Shelley

  • 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.

  • jquerijero wrote:

    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().

    wait-for System.Windows.Forms.Application:Run(oForm).

    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 events
    When 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.

    2313.Form1.cls.zip

    HTH at least a little,

    -- peter

  • So the trick is, if using AppError, to supply a number?

  • 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).

    or

    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.

  • What is the difference by the way?

    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.