Difference between revisions of "Language Reference/Exception Handling"
m (Link corrected) |
m (link) |
||
Line 3: | Line 3: | ||
This section describes the low level constructions for dealing with exceptions in Visual Prolog. PFC does however put a higher level layer on top of this low level mechanisms (see the tutorial [[Exception Handling]]). | This section describes the low level constructions for dealing with exceptions in Visual Prolog. PFC does however put a higher level layer on top of this low level mechanisms (see the tutorial [[Exception Handling]]). | ||
The basic part of the exception handling system is based on the built-in predicate {{lang2|Built-in_entities|errorExit | The basic part of the exception handling system is based on the built-in predicate {{lang2|Built-in_entities|errorExit|errorExit/1}} and the {{lang2|Terms|try-catch-finally|try-catch}} language construction. | ||
* {{lang2|Built-in_entities|errorExit | * {{lang2|Built-in_entities|errorExit|errorExit/1}} raises an exception | ||
* {{lang2|Terms| | * {{lang2|Terms|try-catch-finally|try-catch}} sets an exception handler for a certain computation. | ||
When {{lang2|Built-in_entities|errorExit | When {{lang2|Built-in_entities|errorExit|errorExit/1}} is called the currently active exception handler is invoked. This exception handler is executed in its original context, i.e. in the context where it was set rather than in the context where the exception is raised. | ||
The argument that {{lang2|Built-in_entities|errorExit | The argument that {{lang2|Built-in_entities|errorExit|errorExit/1}} is invoked on is transferred to the exception handler. This argument must somehow provide the needed description of the exception. | ||
Together with additional runtime routines, it is possible to build high-level exception mechanisms on top of this system. | Together with additional runtime routines, it is possible to build high-level exception mechanisms on top of this system. | ||
Line 18: | Line 18: | ||
It is likewise out of the scope of this document to describe how the runtime system deals with exceptions occurring inside the runtime system. | It is likewise out of the scope of this document to describe how the runtime system deals with exceptions occurring inside the runtime system. | ||
The first argument of {{lang2|Terms| | The first argument of {{lang2|Terms|try-catch-finally|try-catch}} is the term to execute with new exception handler. The second argument must be a variable. This variable will be bound to the value {{lang2|Built-in_entities|errorExit|errorExit/1}} is invoked on, if it is invoked while this exception handler is active. The third argument is the exception handler, which will be invoked if {{lang2|Built-in_entities|errorExit|errorExit/1}} is called while this exception handler is active. | ||
The exception handler can access the variable stated in the second argument thereby examining the exception that was raised. | The exception handler can access the variable stated in the second argument thereby examining the exception that was raised. | ||
Line 32: | Line 32: | ||
end try.</vip> | end try.</vip> | ||
If an exception is raised while executing <vp>dangerous</vp>, then <vp>Exception</vp> will be bound to the exception value, and control will be transferred to the third argument of {{lang2|Terms| | If an exception is raised while executing <vp>dangerous</vp>, then <vp>Exception</vp> will be bound to the exception value, and control will be transferred to the third argument of {{lang2|Terms|try-catch-finally|try-catch}}. In this case <vp>Exception</vp> is passed to <vp>handleDangerous</vp>. |
Latest revision as of 10:52, 26 October 2012
This section describes the low level constructions for dealing with exceptions in Visual Prolog. PFC does however put a higher level layer on top of this low level mechanisms (see the tutorial Exception Handling).
The basic part of the exception handling system is based on the built-in predicate errorExit/1 and the try-catch language construction.
- errorExit/1 raises an exception
- try-catch sets an exception handler for a certain computation.
When errorExit/1 is called the currently active exception handler is invoked. This exception handler is executed in its original context, i.e. in the context where it was set rather than in the context where the exception is raised.
The argument that errorExit/1 is invoked on is transferred to the exception handler. This argument must somehow provide the needed description of the exception.
Together with additional runtime routines, it is possible to build high-level exception mechanisms on top of this system.
It is however out of the scope of this document to describe runtime system access routines.
It is likewise out of the scope of this document to describe how the runtime system deals with exceptions occurring inside the runtime system.
The first argument of try-catch is the term to execute with new exception handler. The second argument must be a variable. This variable will be bound to the value errorExit/1 is invoked on, if it is invoked while this exception handler is active. The third argument is the exception handler, which will be invoked if errorExit/1 is called while this exception handler is active.
The exception handler can access the variable stated in the second argument thereby examining the exception that was raised.
Example
clauses p(X) :- try dangerous(X) catch Exception do handleDangerous(Exception) end try.
If an exception is raised while executing dangerous, then Exception will be bound to the exception value, and control will be transferred to the third argument of try-catch. In this case Exception is passed to handleDangerous.