Centura, both code examples and pictures
The idea of handling errors is to avoid programming with return codes like "result_" or "rcode_". The return codes will cause hard-work programming around the calls to stored procedures with lots of IF-statements to check whether there was a 'SUCCESS' or not. Soft errors will in this case appear when the return code is set to an 'ERROR', and hard errors will be raised in separate exception-clauses. A model which handle soft and hard errors in the same manner have been developed based on error handling through exceptions in Oracle. The following sections will completely describe how the error handling is working in a Foundation1 based application.
To understand the model below, some definitions must be made. Within the concepts of error handling, the terms soft and hard errors are often used. Soft errors are often described as application errors that should be handled by the application code. These kinds of errors result in most cases in an error message to the end user. The message is closely connected to the application and will therefore be presented in the selected language. The text also includes business terms, well known by the end user. Hard errors are often described as exceptional errors that are not predestined in any way by the application. These errors are of technical character and are often presented in a server dependent language. For Foundation1 these kinds of errors are typically Oracle errors. Some examples are given below to illustrate the difference between the error types.
A way to get a reasonable error handling is to keep the code as simple as possible, without making any compromises as limited message handling to the end user. This can be made by making the client able to handle all errors in the stored procedure that have been called from the client (including recursive calls). The procedures at lower levels which encounter problems in validation or wrong values of attributes according to the business rules, will just make an Oracle specific "raise_application_error" with a specific error number. This raise-call is not explicitly called, but called through a common service package API for error handling e.g. Error_SYS. All stored procedures and functions between the bottom level (which often produce the error) and the top level client, do not have to check any return codes, they will just propagate any error up through the call stack.
With this model, the client will be able to handle both soft and hard errors in the same way. The common service package API will have support for translating a message to the currently selected language. The client software just fetches the error message and shows it to the end user, irrespective of whether a soft or hard error has occurred. The error handling in the client software as well as the stored procedure programming will therefore be very easy.
Oracle PL/SQL makes it easy to detect and process predefined and user-defined error conditions called "exceptions." When an error occurs, an exception is raised. That is, normal execution stops and control transfers to the exception-handling part of your PL/SQL block or subprogram. To handle raised exceptions, you write separate routines called "exception handlers."
Predefined exceptions are raised implicitly by the runtime system. For example, if you try to divide a number by zero, the predefined exception ZERO_DIVIDE is raised automatically. User-defined exceptions must be raised explicitly by RAISE statements.
You can define exceptions of your own in the declarative part of any PL/SQL block, subprogram, or database trigger. In the executable part, you check for the condition that needs special attention. If you find that the condition exists, you execute a RAISE statement.
It is important to understand how the error handling works when a call to the procedure raise_application_error is used. If an error is raised, the procedure checks if there are any applicable exception-clauses within the procedure, and in that case, the exception code is executed. Otherwise the error is raised up through the call stack.
It is important to state that the default raise handling in PL/SQL is meant
to do just RAISE, even if there exist an exception (for example
NO_DATA_FOUND) in the procedure. Therefore the "WHEN OTHERS"-clause
should not be used, if the result will be just a raise-call. In PL/SQL, it is
always possible to catch any SQL-error by using the pragma
exception_init
with the proper SQL-code.
These messages are divided into two different parts. All of them will be treated exactly the same from Oracle or the client program.
| Type | Description |
|---|---|
| Pre-defined texts | This means that there are interfaces in Error_SYS that have pre-defined error texts to be used when raising the error to the database session. In some cases these messages may be overridden by a user defined message. See the list in Set up Error Handling. |
| User defined texts | This means that there are interfaces in Error_SYS that require a message text to be defined as a parameter. When following programming guidelines, these messages may be translated and presented automatically in another language when running at customer site. |
Error handling serves the purpose of catching errors, presenting/logging the error and where possible explaining the error. The IFS/Client framework differences between two kinds of errors:
User errors occur as the result of an illegal action from the user, i.e. entering invalid field values, or leaving a mandatory field empty. Many user errors are handled automatically by the framework, but there will certainly be cases when an application needs to handle user errors.
User errors should always be translatable (to become presentented into the user's selected language in runtime), and be written with a non-technical language. For these reasons, applications should always use the AlertBox or AlertBoxWithParams when showing user errors.
Example of User Error
Internal errors are the result of an unexpected program execution, such as the missing of a function, or an SQL statement that fails to execute. In most cases, there is no need for applications to handle internal error since the framework automatically handles them in calls to any Db* functions.
If the application for some reason needs to handle internal errors, it should always use the ErrorReport function to report the message. Using the ErrorReport function assures that the error is reported, logged etc. in the correct way.
Example of Internal Error