onErrCall
onErrCall*( errorMethod : string )
onErrCall( errorMethod : string , scope : integer )
| Parameter | Type | Description | |
|---|---|---|---|
| errorMethod | string | → | Parameters used to build the error |
| scope | integer | → | Scope for the error method |
Description
The onErrCall command installs the project method, whose name you pass in errorMethod, as the method for catching (trapping) errors for the defined execution context in the current project. This method is called the error-handling method.
The scope of the command designates the execution context from where an error will trigger the call of the errorMethod. By default, if the scope parameter is omitted, the scope of the command is the local execution context, i.e. the current process. You can pass one of the following constants in the scope parameter:
| Constant | Value | Description |
|---|---|---|
| ek errors from components | 2 | Only errors generated from the components installed in the application will call errorMethod. Note that, if an error-handling method is defined in a component, it is called in case of error in the component, and the ek errors from components error handler set in the host application is not called. |
| ek global | 1 | All errors that occurred in the application, whatever the process (except components), will call errorMethod. Note that, if a ek local error handler is also defined for a process, the ek global error handler is not called. This principle allows you to define a generic error-handling method that will catch all errors, while local error-handling methods can be set for some specific processes. |
| ek local | 0 | (default if scope parameter is omitted) Only errors that occurred in the current process will call errorMethod. You can have one error-handling method per process at a time, but you can have different error-handling methods for several processes. |
To stop the trapping of errors, call onErrCall again with the desired scope parameter (if any) and pass an empty string in errorMethod.
You can use the lastErrors and callChain commands to obtain the error sequence (i.e., the error "stack") at the origin of the interruption (see also Handling errors within the method).
The error-handling method should manage the error in an appropriate way or present an error message to the user. Errors can be generated by the Qodly database engine (e.g. saving an entity causes the violation of a rule), the Qodly environment (e.g. have enough memory for loading a blob)...
The abort command can be used to terminate processing. If you don't call abort in the error-handling method, Qodly returns to the interrupted method and continues to execute the method. Use the abort command when an error cannot be recovered.
If an error occurs in the error-handling method itself, Qodly takes over error handling. Therefore, you should make sure that the error-handling method cannot generate an error. Also, you cannot use onErrCall inside the error-handling method.
Example 1
You want to install a global error handler:
onErrCall("myGlobalErrorHandler",ek global)
Example 2
Here is a simple error-handling system:
// installing the error handling method
onErrCall("errorMethod")
//... executing code
onErrCall("") //giving control back to Qodly
// errorMethod project method
var errNum : integer
var message : string
errNum = lastErrors[0].errCode
if(errNum != 1006) //this is not a user interruption
message = "Error "+string(errNum)+" occurred ("+lastErrors[0].message+").")
end