Choosing a handler
An unhandled error is sent one level up
into the outer PL/pgSQL block, if available
into the calling routine, if available
The search path of a handler is determined by the call stack
it is not defined statically, but depends on how the program executes
An unhandled error is passed to the client
the transaction enters the failure mode and has to be rolled back by the client
the error is registered in the server log
If none of the conditions listed in the EXCEPTION section is triggered, the
error goes one level up.
If an error has occurred in the inner block of a nested structure, the server
will search for a handler in the outer block. If there is no suitable handler
either, the whole outer block will be treated as failed, while the error will be
passed to the next nesting level, and so on.
If the error goes through the whole nested structure and does not find an
appropriate handler, it goes further up to the level of the routine that has
called the outermost block. Therefore, you have to analyze the call stack to
determine the order in which different error handlers will be applied.
If none of the available error handlers is triggered:
●
The error message usually gets into the server log (the exact behavior
depends on the server settings),
●
The error is reported to the client that has initiated this operation in the
database. The client cannot do anything about the cause of the error at
this point: the transaction enters the failure mode, and it can only be
rolled back.
It is up to the client to choose how to handle the error from there. For
example, psql will display the error message and all the debugging
information available. An end-user client may display a generic message
like “contact your system administrator”.