Error Handling
Application Errors
Error messages to the end-user can be created by running the SetMessage procedure in combination with the parameter oiReturnStatus.
An error condition is raised when you assign a negative value to t_Parameter.oiReturnStatus. When this occurs, standard business logic stops executing and passes the return status to the client that runs the business logic.
Note: The ValidateComponent and ValidateBC methods are exceptions to this behavior. When the return value for oiReturnStatus is negative, these methods continue to execute and attempt to validate the component.
The possible values for oiReturnStatus are:
• -1 Validation error
The input for the operation was incorrect. The operation could not proceed.
• -3 Run-time error
The operation did not proceed because of a run-time error in the operation code.
• -5 Fatal error
The operation did not proceed because of a permanent error. The application is shut down.
System Errors
System errors are triggered by Progress run-time when a Progress statement without the no-error option fails to execute. System errors are handled by the standard business logic using the new try-catch mechanism of OpenEdge 10. You must then ensure that any sub-transaction block (for example, a do transaction, for, or repeat block) in your code includes the on error undo, throw option.
System errors are reported using oiReturnStatus -98.
You can also add a finally block at the end of a customization event procedure. Code in a finally block is always executed before the procedure ends. It is also run when a system error occurs during the execution of a procedure or if the code is interrupted with an explicit return statement.
Database Access and Updates
There are no rules or restrictions on database access and updates. Each event is a transaction on its own and all updates to it are committed when the event ends. The exceptions to this are the events on the business method
DataSaveWorker and the sub-methods
PreSave and
PostSave (see
Identifying Events). These methods are typically contained in larger transactions, and updates to them are not implemented if the larger transactions fail.
Inheritance
When you implement an event on a business component that has descendant business components, the event is also implemented for all the descendants, except descendants that override the standard business logic for that specific method.
Example:
Inheritance Structure
Any customization event implemented on bbasedaemon is active when running the component bxmldaemon, breportdaemon or any other daemon.