Exception Handling v11

Suggest edits

By default, any error occurring in an SPL program aborts execution of the program. You can trap errors and recover from them by using a BEGIN block with an EXCEPTION section. The syntax is an extension of the normal syntax for a BEGIN block:

[ DECLARE
    <declarations> ]
  BEGIN
    <statements>
  EXCEPTION
    WHEN <condition> [ OR <condition> ]... THEN
      <handler_statements>
  [ WHEN <condition> [ OR <condition> ]... THEN
      <handler_statements> ]...
END;

If no error occurs, this form of block simply executes all the statements, and then control passes to the next statement after END. If an error occurs within the statements, further processing of the statements is abandoned, and control passes to the EXCEPTION list. The list is searched for the first condition matching the error that occurred. If a match is found, the corresponding handler_statements are executed, and then control passes to the next statement after END. If no match is found, the error propagates out as though the EXCEPTION clause were not there at all. The error can be caught by an enclosing block with EXCEPTION; if there is no enclosing block, it aborts processing of the subprogram.

The special condition name OTHERS matches every error type. Condition names are not case-sensitive.

If a new error occurs within the selected handler_statements, it cannot be caught by this EXCEPTION clause, but is propagated out. A surrounding EXCEPTION clause could catch it.

The following table lists the condition names that may be used:

Condition NameDescription
CASE_NOT_FOUNDThe application has encountered a situation where none of the cases in CASE statement evaluates to TRUE and there is no ELSE condition.
COLLECTION_IS_NULLThe application has attempted to invoke a collection method on a null collection such as an uninitialized nested table.
CURSOR_ALREADY_OPENThe application has attempted to open a cursor that is already open.
DUP_VAL_ON_INDEXThe application has attempted to store a duplicate value that currently exists within a constrained column.
INVALID_CURSORThe application has attempted to access an unopened cursor.
INVALID_NUMBERThe application has encountered a data exception (equivalent to SQLSTATE class code 22). INVALID_NUMBER is an alias for VALUE_ERROR.
NO_DATA_FOUNDNo rows satisfy the selection criteria.
OTHERSThe application has encountered an exception that hasn’t been caught by a prior condition in the exception section.
SUBSCRIPT_BEYOND_COUNTThe application has attempted to reference a subscript of a nested table or varray beyond its initialized or extended size.
SUBSCRIPT_OUTSIDE_LIMITThe application has attempted to reference a subscript or extend a varray beyond its maximum size limit.
TOO_MANY_ROWSThe application has encountered more than one row that satisfies the selection criteria (where only one row is allowed to be returned).
VALUE_ERRORThe application has encountered a data exception (equivalent to SQLSTATE class code 22). VALUE_ERROR is an alias for INVALID_NUMBER.
ZERO_DIVIDEThe application has tried to divide by zero.
User-defined ExceptionSee User-defined Exceptions.
Note

Condition names INVALID_NUMBER and VALUE_ERROR are not compatible with Oracle databases for which these condition names are for exceptions resulting only from a failed conversion of a string to a numeric literal. In addition, for Oracle databases, an INVALID_NUMBER exception is applicable only to SQL statements while a VALUE_ERROR exception is applicable only to procedural statements.

← Prev

Loops

Next →

User-defined Exceptions