Notice of behavior change in OpenEdge 10.2B

Posted by sarahm on 19-May-2009 11:51

Change in behavior with regard to handling .NET events in the ABL, and error conditions:
In OpenEdge 10.2A it is possible for an ABL application to subscribe to a .NET event.  When .NET fires the event, the ABL routine designated as the event handler by the subscriber executes.  There may be multiple subscribers to that event (both ABL and .NET) and in that case, when the event fires, the event handlers for all of the subscribers will run.
If the ABL routine designated as an event handler for a .NET event raises error (which can occur in a variety of different ways) the current behavior in OpenEdge 10.2A is that the error messages are displayed to the standard output device, but no indication that an error occurred is communicated back to .NET, and execution continues with the next event handler, should there be multiple subscribers, or with the normal execution path following the code that fires the event. 
In OpenEdge 10.2B this behavior will change.  As part of our continued development of object-oriented language features and integration with .NET, 10.2B will include the facility to define and subscribe to strongly typed ABL events.  Part of this effort is to maintain consistency in the way that errors from ABL routines are handled, and to assure that ABL event handlers and .NET event handlers comply with the same error handling model with respect to .NET events.  From this perspective we feel the 10.2A behavior described above is incorrect.
The behavior in OpenEdge 10.2B will be as follows:  When an event handler for a .NET event raises error, the error messages will no longer be displayed to the standard output device, but rather a System.ApplicationException will be thrown to .NET.  .NET will catch the exception and handle it according to the .NET error handling model.  This means that no further event handlers, if there are any, will be executed and the code following that which fired the event will not execute.  Although this represents a different code path, this is the way that .NET handles error conditions from event handlers.
The purpose of this notice is to make ABL programmers aware of the coming change in behavior as they work on their GUI for .NET applications, and to solicit feedback concerning the change.

OpenEdge Development - Forum

All Replies

Posted by Admin on 19-May-2009 13:26

Sounds reasonable.

Posted by jmls on 22-May-2009 11:37

So a CATCH block would not be executed ? Or will it ?

I guess that it is obvious I am confused

Posted by sarahm on 22-May-2009 12:26

No, an ABL CATCH will not execute if the event was fired by .NET.  Instead the .NET routine that fired the event will handle it with a .NET catch mechanism.  On the other hand, if the event that fired was an ABL event, then a CATCH in the ABL routine that fired the event can handle any errors that occur.   

Posted by whenshaw on 30-Nov-2009 14:08

We have decided not to go through with this change for handlers of .NET events in 10.2B. We realized that with the change, there could be times when an OpenEdge system error (for example, inability to run a handler) would be suppressed by the .NET code that fired the event and therefore would never be noticed by the developer.

So -- the AVM will continue to process errors raised by an ABL handler for a .NET event just as it does in 10.2A. Any error message will be displayed to standard output, and no indication that there was an error will be returned to .NET. If there are additional event handlers queued to run, they will be invoked.

Note that the above applies only to handlers for .NET events. For ABL events, if a handler raises an error, the error will be raised on the statement that includes the Publish(). If there are additional handlers queued for that Publish, they will not run.

This thread is closed