Before
the introduction of exceptions in SWI-Prolog a runtime error was handled
by printing an error message, after which the predicate failed. If the
Prolog flag debug_on_error
was in effect (default), the tracer was switched on. The combination of
the error message and trace information is generally sufficient to
locate the error.
With exception handling, things are different. A programmer may wish
to trap an exception using catch/3
to avoid it reaching the user. If the exception is not handled by user
code, the interactive top level will trap it to prevent termination.
If we do not take special precautions, the context information
associated with an unexpected exception (i.e., a programming error) is
lost. Therefore, if an exception is raised which is not caught using
catch/3
and the top level is running, the error will be printed, and the system
will enter trace mode.
If the system is in a non-interactive call-back from foreign code and
there is no catch/3
active in the current context, it cannot determine whether or not the
exception will be caught by the external routine calling Prolog. It will
then base its behaviour on the Prolog flag
debug_on_error:
- current_prolog_flag(debug_on_error, false)
The exception does not trap the debugger and is returned to the foreign
routine calling Prolog, where it can be accessed using PL_exception().
This is the default.
- current_prolog_flag(debug_on_error, true)
If the exception is not caught by Prolog in the current context, it will
trap the tracer to help analyse the context of the error.
While looking for the context in which an exception takes place, it
is advised to switch on debug mode using the predicate debug/0.
The hook
prolog_exception_hook/4
can be used to add more debugging facilities to exceptions. An example
is the library library(http/http_error), generating a full
stack trace on errors in the HTTP server library.
