An error handler has 3 optional arguments. The first argument is the number that identifies the error, the second argument is the culprit (a structure corresponding to the call which caused the error). For instance, if, say, a type error occurs upon calling the third goal of the procedure p(2, Z):
the structure given to the error handler is b(2, Y). Note that the handler could bind Y which would have the same effect as if b/2 had done the binding.p(X, Y) :- a(X), b(X, Y), c(Y).
The third argument is only defined for a subset of the existing errors.
If the error occurred inside a tool body, it holds the caller module,
otherwise it is a free variable.
Note that some events are not errors but are used for different purposes.
In thoses cases the second and third argument are sometimes used
differently. See Appendix 
for details.
The error handler is free to ignore some of these arguments,
i.e. it can have any arity from 0 to 3.
The first argument is provided for the case that the same procedure serves
as the handler for several error types - then it can distinguish
which is the actual error type.
An error handler is just an ordinary Prolog procedure
,
and thus within
it a call may be made to any other procedure, or any built in predicate;
this in particular means that a call to exit_block/1 may be
made (see the section on the block/3
predicate). This will work
'through' the call to the error handler, and so an exit may be made from
within the handler out of the current block (i.e. back to the corresponding
call of the block/3 predicate).
Specifying the predicates true/0 or fail/0 as error handlers
will make the erroneous predicate succeed (without binding
any further variables) or fail respectively.