.NET errors are represented by error objects known as exceptions, and the .NET System.Exception class is the base class for all .NET Exception objects. To enable an ABL application to trap .NET exceptions that are raised from .NET objects, OpenEdge has enhanced System.Exception to implement the Progress.Lang.Error interface. By implementing this interface, most .NET exceptions that are raised in the ABL context can be handled by both traditional and structured ABL error handling constructs in much the same way as ABL errors.
When using structured error handling, you can catch and throw a System.Exception object and consult the same properties and methods as for a Progress.Lang.ProError class.
Some .NET UI controls trap and handle errors before they get to the AVM. However, some kinds of exceptions, such as System.AccesssViolationException, cause Application:Run( ) to terminate and raise a STOP condition on the executing WAIT-FOR or PROCESS EVENTS statement. You can trap this condition using the ON STOP phrase of an enclosing block. However, because Application:Run( ) exits and all displayed forms are closed, the most that you can do is to clean-up and attempt a graceful close of your application.
All .NET exceptions have a Message property from the System.Exception base class. In addition, if there was a chain of errors that lead to the current exception, an InnerException property references the most recent Exception object in that chain of Exception objects, and so on, for any number of inner exceptions. Each inner exception, then, is just another Exception object (or something derived from it), with its own Message property. In addition, specific types of Exception objects have additional information available from custom properties. For example, the FileNotFoundException has a FileName property, which is the name of the file that cannot be found.
Your ABL application can access all of the messages in the .NET Exception object (i.e., the message from the object itself plus any from inner exceptions) using the methods of Progress.Lang.Error. However, if you want to access any additional information such as the FileName custom property of the FileNotFoundException object, you must do so using the native properties and methods of the .NET Exception object itself.
Some .NET UI controls trap and handle errors before they get to the AVM. However, some kinds of exceptions, such as System.AccesssViolationException, cause Application:Run( ) to terminate and raise a STOP condition on the executing WAIT-FOR or PROCESS EVENTS statement. You can trap this condition using the ON STOP phrase of an enclosing block. However, because Application:Run( ) exits and all displayed forms are closed, the most that you can do is to clean-up and attempt a graceful close of your application.