4.15.3.1 Protecting a Particular Goal

The built-in predicate on_exception/3 enables you to handle exceptions to a specific goal:

     on_exception(?ExceptionCode, :ProtectedGoal, :Handler)

ProtectedGoal is executed. If all goes well, it will behave just as if you had written ProtectedGoal without the on_exception/3 wrapper. If an exception is raised while ProtectedGoal is running, Prolog will abandon ProtectedGoal entirely. Any bindings made by ProtectedGoal will be undone, just as if it had failed. If the exception occurred in the scope of a call_cleanup(Goal,Cleanup), Cleanup will be called. Side-effects, such as asserts and retracts, are not undone, just as they are not undone when a goal fails. After undoing the bindings, Prolog tries to unify the exception term raised with the ExceptionCode argument. If this unification succeeds, Handler will be executed as if you had written

     ExceptionCode=<the actual exception term>,
     Handler

If this unification fails, Prolog will keep searching up the ancestor list looking for another exception handler. If it reaches Prolog's top-level (or a break level) without having found a call to on_exception/3 with a matching ExceptionCode, an appropriate error message is printed (using print_message/2).

ProtectedGoal need not be determinate. That is, backtracking into ProtectedGoal is possible, and the exception handler becomes reactivated in this case. However, if ProtectedGoal is determinate, the call to on_exception/3 is also determinate.

The ProtectedGoal is logically inside the on_exception/3 form, but the Handler is not. If an exception is raised inside the Handler, this on_exception/3 form will not be reactivated. If you want an exception handler that protects itself, you have to program it, perhaps like this:

     recursive_on_exception_handler(Err, Goal, Handler) :-
         on_exception(Err, Goal,
             recursive_on_exception_handler(Err, Handler, Handler)).

Certain built-in and library predicates rely on the exception mechanism, so it is usually a bad idea to let Pattern be a variable, matching any exception. If it must be a variable, the Handler should examine the exception and pass it on if it is not relevant to the current invocation.

In a development system, any previously uncaught exception is caught and an appropriate error message is printed before returning to the top-level. In recursive calls to Prolog from C, uncaught exceptions are returned back to C instead. The printing of these and other messages in a development system is handled by the predicate print_message/2 (see ref-msg).

catch(ProtectedGoal, ExceptionCode, Handler) is the same as on_exception(ExceptionCode, ProtectedGoal, Handler).


Send feedback on this subject.