Language Reference/Exception Handling - Revision history

Thomas Linder Puls: link

2012-10-26T09:52:07Z

link

Thomas Linder Puls: Link corrected

2008-11-09T10:35:23Z

Link corrected

← Older revision		Revision as of 12:35, 9 November 2008
Line 1:		Line 1:
	{{languageReferenceNavbar\|Exception Handling}}		{{languageReferenceNavbar\|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 [[~~Exceptions~~ 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.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-catch-finally\|try-catch}} language construction.		The basic part of the exception handling system is based on the built-in predicate {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-catch-finally\|try-catch}} language construction.

Thomas Linder Puls: see exception handling

2008-10-20T14:10:31Z

see exception handling

← Older revision		Revision as of 16:10, 20 October 2008
Line 1:		Line 1:
	{{languageReferenceNavbar\|Exception Handling}}		{{languageReferenceNavbar\|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 [[Exceptions 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 [[Exceptions Handling]]).

	The basic part of the exception handling system is based on the built-in predicate {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-catch-finally\|try-catch}} language construction.		The basic part of the exception handling system is based on the built-in predicate {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-catch-finally\|try-catch}} language construction.

Thomas Linder Puls: PFC exception handling

2008-10-20T13:32:27Z

PFC exception handling

← Older revision		Revision as of 15:32, 20 October 2008
Line 1:		Line 1:
	{{languageReferenceNavbar\|Exception Handling}}		{{languageReferenceNavbar\|Exception Handling}}

	The basic part of the exception handling system is based on the built-in predicate {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-~~fatch~~-finally\|try-catch}} language construction.		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 [[Exceptions Handling]]

			The basic part of the exception handling system is based on the built-in predicate {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-catch-finally\|try-catch}} language construction.

	* {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} raises an exception		* {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} raises an exception
	* {{lang2\|Terms\|Try-~~fatch~~-finally\|try-catch}} sets an exception handler for a certain computation.		* {{lang2\|Terms\|Try-catch-finally\|try-catch}} sets an exception handler for a certain computation.

	When {{lang2\|Built-in_entities\|errorExit.2F1\|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.		When {{lang2\|Built-in_entities\|errorExit.2F1\|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.
Line 16:		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\|Try-~~fatch~~-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.2F1\|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.2F1\|errorExit/1}} is called while this exception handler is active.		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.2F1\|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.2F1\|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 30:		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\|Try-~~fatch~~-finally\|try-catch}}. In this case <vp>Exception</vp> is passed to <vp>handleDangerous</vp>.		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>.

Thomas Linder Puls: update to try-catch

2008-10-20T12:12:07Z

update to try-catch

← Older revision		Revision as of 14:12, 20 October 2008
Line 1:		Line 1:
	{{languageReferenceNavbar\|Exception Handling}}		{{languageReferenceNavbar\|Exception Handling}}

	The basic part of the exception handling system is based on the ~~two~~ built-in ~~predicates~~ {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and {{lang2\|~~Built~~-~~in_entities~~\|~~Predicates\|trap/3~~}}.		The basic part of the exception handling system is based on the built-in predicate {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} and the {{lang2\|Terms\|Try-fatch-finally\|try-catch}} language construction.

	*~~<vp>~~errorExit</~~vp>~~ raises an exception		* {{lang2\|Built-in_entities\|errorExit.2F1\|errorExit/1}} raises an exception
	*~~<vp>trap</vp>~~ sets an exception handler for a certain computation.		* {{lang2\|Terms\|Try-fatch-finally\|try-catch}} sets an exception handler for a certain computation.

	When ~~<vp>~~errorExit</~~vp>~~ 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.		When {{lang2\|Built-in_entities\|errorExit.2F1\|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 ~~<vp>~~errorExit</~~vp>~~ is invoked on is transferred to the exception handler. This argument must somehow provide the needed description of the exception.		The argument that {{lang2\|Built-in_entities\|errorExit.2F1\|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 16:		Line 16:
	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 ~~<vp>trap</vp>~~ is the term to execute with new exception handler. The second argument must be a variable. This variable will be bound to the value ~~<vp>~~errorExit</~~vp>~~ 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 ~~<vp>~~errorExit</~~vp>~~ is called while this exception handler is active.		The first argument of {{lang2\|Terms\|Try-fatch-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.2F1\|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.2F1\|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 23:		Line 23:

	<vip>clauses		<vip>clauses
	p(X) :-		p(X) :-
	~~trap(~~ dangerous(X), Exception, handleDangerous(Exception)).</vip>		try
			dangerous(X)
			catch Exception do
			handleDangerous(Exception)
			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 ~~<vp>trap</vp>~~. In this case <vp>Exception</vp> is passed to <vp>handleDangerous</vp>.		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-fatch-finally\|try-catch}}. In this case <vp>Exception</vp> is passed to <vp>handleDangerous</vp>.

Thomas Linder Puls: 1 revision(s)

2008-09-15T14:22:15Z

1 revision(s)

← Older revision	Revision as of 16:22, 15 September 2008
(No difference)

Thomas Linder Puls: /* Exception Handling */

2008-09-15T13:37:18Z

Exception Handling

New page

{{languageReferenceNavbar|Exception Handling}}

The basic part of the exception handling system is based on the two built-in predicates {{lang2|Built-in_entities|errorExit.2F1|errorExit/1}} and {{lang2|Built-in_entities|Predicates|trap/3}}.

*<vp>errorExit</vp> raises an exception
*<vp>trap</vp> sets an exception handler for a certain computation.

When <vp>errorExit</vp> 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 <vp>errorExit</vp> 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 <vp>trap</vp> is the term to execute with new exception handler. The second argument must be a variable. This variable will be bound to the value <vp>errorExit</vp> 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 <vp>errorExit</vp> 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'''

<vip>clauses
p(X) :-
trap( dangerous(X), Exception, handleDangerous(Exception)).</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 <vp>trap</vp>. In this case <vp>Exception</vp> is passed to <vp>handleDangerous</vp>.

← Older revision		Revision as of 11:52, 26 October 2012
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~~.2F1~~\|errorExit/1}} and the {{lang2\|Terms\|~~Try~~-catch-finally\|try-catch}} language construction.		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~~.2F1~~\|errorExit/1}} raises an exception		* {{lang2\|Built-in_entities\|errorExit\|errorExit/1}} raises an exception
	* {{lang2\|Terms\|~~Try~~-catch-finally\|try-catch}} sets an exception handler for a certain computation.		* {{lang2\|Terms\|try-catch-finally\|try-catch}} sets an exception handler for a certain computation.

	When {{lang2\|Built-in_entities\|errorExit~~.2F1~~\|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.		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~~.2F1~~\|errorExit/1}} is invoked on is transferred to the exception handler. This argument must somehow provide the needed description of the exception.		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\|~~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~~.2F1~~\|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~~.2F1~~\|errorExit/1}} is called while this exception handler is active.		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\|~~Try~~-catch-finally\|try-catch}}. In this case <vp>Exception</vp> is passed to <vp>handleDangerous</vp>.		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>.