Service Studio provides the Error Handler element to handle exceptions. This element can be used in the action flow or screen flow. An error handler catches a specific exception.
There is a call hierarchy for exceptions that determines the error handler behavior:
The most general exception is All Exceptions, which includes User exceptions, Database, Security, Abort Activity Change, and Licensing exceptions. This means that an error handler for AllExceptions handles any of these exceptions, if there is not a more specific error handler.
User exceptions include all the exceptions that can be explicitly raised in your eSpace. This means that an error handler associated with "User exceptions" would handle any user exception, if there is not a more specific error handler defined.
Database exceptions which handle any exception caused by an error in the database. These exceptions cannot be explicitly by the eSpace logic;
Security exceptions include Invalid Login, Not Registered, and role exceptions. This means that an error handler associated with "Security" would handle any of these exceptions, if there is not a more specific Error Handler;
Abort Activity Change exceptions which only handles Abort Activity change exceptions that are explicitly raised in the eSpace logic.
Exception Handling Mechanism
Whenever an exception is raised the execution is interrupted and continues in the Error Handler that is suited to handle the exception.
To select the Error Handler for an exception, the OutSystems Platform proceeds as follows:
In the current action, find out if there is an error handler for the specific exception that was raised;
In the current action, find out if there is a generic error handler;
Follow the caller stack until an error handler is found or the end of the stack is reached;
When a suitable error handler is found, execute its logic and continue processing the end-user request.
In the scenario above, when the GetCityWeather action raises an InvalidWSResponse user exception, the error handling mechanism works as follows:
Check if the GetCityWeather has an error handler for InvalidWSResponse exceptions;
Check if the GetCityWeather has a generic error handler: User Exception handler, or All Exceptions handler;
Follow the caller stack: since the GetWeather action called the GetCityWeather action, the algorithm searches in the GetWeather for an InvalidWSResponse, UserException, or All Exceptions hander (in this order);
Follow the caller stack: since the HomePage screen belongs to the MainFlow, check if the MainFlow for an InvalidWSResponse, UserException, or All Exceptions hander (in this order);
If an error handler is found along the way, execute its flow and continue with the user request. Otherwise, redirect the end-user to a page with the error stack trace and the error is logged.
Error Handling Flow
To avoid displaying generic error messages to end-users, it is possible to define a global error handler, that is checked if no error handler is found in the caller stack:
In the eSpace Theme, specify the screen flow that contains generic error handlers by setting the Theme 'Error Handling Flow' property;
In the Screen Flow you have specified, add an All Exceptions exception handler. This ensures that if no other handler exists, then the end-user is redirected to a specific screen.
Error Handler Properties | Types of Exceptions