Service Studio provides the Error Handler element to handle exceptions. This element can be used in a screen flow (Collection of objects that define the user interaction; you can have screens, entry points, external sites, etc, depending on the type of your flow. The objects are linked through Connectors.) or action flow (Collection of elements that graphically implements the behavior of an action. You can have assign and control elements, exception handlers or you can invoke other actions. The elements are linked through Connectors.); it depends of the logic that you want to implement. An Error handler catches a specific exception. Its possible values are: Database, Security and its children, Licensing, User Exceptions and their children, and All Exceptions.

The exception handled by an Error Handler is specified in the Exception property. How

There is a hierarchy between these exceptions that determines the Error Handler behavior, described below.

• The most general exception is All Exceptions, which includes User exceptions, Database, Licensing, and Security exceptions. This means that an Error Handler associated with AllExceptions would handle any of these exceptions, if there is not a more specific Error Handler.

• User exceptions include all the exceptions that you explicitly create 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.

• Database Exceptions which handle any exception caused by an error in the database. These exceptions cannot be explicitly raise in 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.

Exception Handling Mechanism

Whenever an exception is raised the execution is interrupted and switched over to the Error Handler that is suited to handle the exception.

To select the Error Handler the algorithm proceeds as follows:

1. In the current Web Flow or Action Flow

1. Find out an Error Handler that is specific for the exception;

2. Find out an Error Handler that is generic and handles the exception. For example, the Invalid Login exception may be handled by (1) Security or (2) AllExceptions Error Handlers.

2. Follow the Caller Stack

The caller stack is followed and the previous step (Step 1) is repeated for each element found in the stack. This cycle stops either when an Error Handler is found for the exception or the end of the stack has been reached.

As an example, imagine the following scenario:

• The CalculateAveragePrices action executes the GetAllItems and CalculateAveragePriceForItem actions;

• The CalculateAveragePrices action has an error handler for AllExceptions;

• Neither the GetAllItemsAveragePrices and CalculateAveragePriceForItem actions have Error Handlers.

In this case, any exception that is raised in any of these three actions will be always handled by the Error Handler defined in the CalculateAveragePrices action.

3. Use the Exception Web Flow

If the eSpace's Exception Web Flow is defined, find out a suited Error Handler for the exception in this special Web Flow.

You should have a global Error Handler in the eSpace's Exception Web Flow to make sure you catch all exceptions raised in the eSpace and provide a more user-friendly message.

If at this point the exception has not been handled, your application aborts and an error is logged in the platform error log entity (in Service Center). If the exception was raised during the execution of an end-user request (web access, for example), the end-user is presented with a generic error page.

See Also

Error Handler Properties | Types of Exceptions