Exception Handling - Revision history

Badge at 23:56, 3 June 2009

2009-06-03T23:56:07Z

← Older revision		Revision as of 23:56, 3 June 2009
Line 2:		Line 2:

	All input/output statements in Internet Basic allow for handling of runtime exceptions.<br>		All input/output statements in Internet Basic allow for handling of runtime exceptions.<br>
-	Here are some typical examples:	+	Here are some typical examples:

	*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)		*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)

Badge at 23:55, 3 June 2009

2009-06-03T23:55:40Z

← Older revision		Revision as of 23:55, 3 June 2009
Line 50:		Line 50:
	\|-		\|-
	\|}		\|}
-	In an exception routine, there are several ways to deal with runtime exceptions. One way is to simply branch back to a logical starting place in the program and start over. Another is to retry the action that caused the exception. This is done with the AGAIN statement.	+	In an exception routine, there are several ways to deal with runtime exceptions.<br>
		+	One way is to simply branch back to a logical starting place in the program and start over.<br>
		+	Another is to retry the action that caused the exception. This is done with the AGAIN statement.<br>
	Another course is to instruct the program to come to an abnormal end, in the case where all possible exceptions have been tested for and handled.		Another course is to instruct the program to come to an abnormal end, in the case where all possible exceptions have been tested for and handled.

Badge at 23:54, 3 June 2009

2009-06-03T23:54:36Z

← Older revision		Revision as of 23:54, 3 June 2009
Line 1:		Line 1:
	== Exception Handling ==		== Exception Handling ==

-	All input/output statements in Internet Basic allow for handling of runtime exceptions. Here are some typical examples:	+	All input/output statements in Internet Basic allow for handling of runtime exceptions.<br>
		+	Here are some typical examples:

	*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)		*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)
Line 13:		Line 14:
	* While reading through a data file in sequential (or key-sequential) order, the program reaches the last record in the file, but attempts to read one more record. (Result: Comet exception 2 -- end-of-file.)		* While reading through a data file in sequential (or key-sequential) order, the program reaches the last record in the file, but attempts to read one more record. (Result: Comet exception 2 -- end-of-file.)

-	Each of the above situations results in a Comet runtime exception. The EXCP=statement-label parameter is used to specify an "exception path" to follow if an exception occurs during program execution.<br> For example:	+	Each of the above situations results in a Comet runtime exception.<br>
		+	The EXCP=statement-label parameter is used to specify an "exception path" to follow if an exception occurs during program execution.<br>
		+	'''For example:'''

	READ (1,1000) KEY=CUSTNUM$, EXCP=9999		READ (1,1000) KEY=CUSTNUM$, EXCP=9999
Line 56:		Line 59:
	ERROR		ERROR

-	In this exception routine, if the exception is 33, the program will display a message that the record is extracted and try the I/O statement again (as specified by the AGAIN statement). Note: This method should be used with care, as it could result in and endless loop of trying the I/O statement, testing for exception 33, trying the I/O statement, etc.	+	In this exception routine, if the exception is 33, the program will display a message that the record is extracted and try the I/O statement again (as specified by the AGAIN statement).<br>
-	In the above routine, if exceptions 32 and 33 are not the cause, the program is instructed to take an abnormal end (the ERROR statement does this). When ERROR is encountered, the QENDITOR program will be executed and the Comet exception will be displayed on the controlling terminal.	+	'''Note:''' This method should be used with care, as it could result in and endless loop of trying the I/O statement, testing for exception 33, trying the I/O statement, etc. <br>
		+	In the above routine, if exceptions 32 and 33 are not the cause, the program is instructed to take an abnormal end (the ERROR statement does this).<br>
		+	When ERROR is encountered, the QENDITOR program will be executed and the Comet exception will be displayed on the controlling terminal.

-	Other exception handling statements include ERRORTO and ERRORSUB, statements that set default exception paths. Comet32 includes the NOEXCP option on file system statements so you may choose to ignore any non-fatal exception.	+	Other exception handling statements include ERRORTO and ERRORSUB, statements that set default exception paths.<br>
		+	Comet32 includes the NOEXCP option on file system statements so you may choose to ignore any non-fatal exception.

Badge at 23:52, 3 June 2009

2009-06-03T23:52:02Z

← Older revision		Revision as of 23:52, 3 June 2009
Line 17:		Line 17:
	READ (1,1000) KEY=CUSTNUM$, EXCP=9999		READ (1,1000) KEY=CUSTNUM$, EXCP=9999

-	In this example, a statement-label of 9999 is specified as the exception path for the READ statement. This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending. <br>	+	In this example, a statement-label of 9999 is specified as the exception path for the READ statement.<br>
		+	This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending. <br>
	There are two exception branching parameters:		There are two exception branching parameters:

Line 24:		Line 25:
	EXCPSUB=statement-label branches to subroutine		EXCPSUB=statement-label branches to subroutine

-	In any exception routine, the program may include statements to inquire into the nature of the exception. This is done with the Comet system variable named EXCP, which contains the number of the most recently encountered Comet exception.	+	In any exception routine, the program may include statements to inquire into the nature of the exception. This is done with the Comet system variable named EXCP, which contains the number of the most recently encountered Comet exception.<br>
-	See Comet exception messages for a complete list of runtime exceptions.	+	See [[Exception_Messages\|Comet exception messages]] for a complete list of runtime exceptions.

	Following the example from above, an exception routine could look like this:		Following the example from above, an exception routine could look like this:

Badge at 23:47, 3 June 2009

2009-06-03T23:47:12Z

← Older revision		Revision as of 23:47, 3 June 2009
Line 41:		Line 41:
	\|32		\|32
	\|The specified key was not found in the key list		\|The specified key was not found in the key list
		+	\|-
	\|33		\|33
	\|The specified key was extracted by another user		\|The specified key was extracted by another user

Badge at 23:46, 3 June 2009

2009-06-03T23:46:31Z

← Older revision		Revision as of 23:46, 3 June 2009
Line 13:		Line 13:
	* While reading through a data file in sequential (or key-sequential) order, the program reaches the last record in the file, but attempts to read one more record. (Result: Comet exception 2 -- end-of-file.)		* While reading through a data file in sequential (or key-sequential) order, the program reaches the last record in the file, but attempts to read one more record. (Result: Comet exception 2 -- end-of-file.)

-	Each of the above situations results in a Comet runtime exception. The EXCP=statement-label parameter is used to specify an "exception path" to follow if an exception occurs during program execution. For example:	+	Each of the above situations results in a Comet runtime exception. The EXCP=statement-label parameter is used to specify an "exception path" to follow if an exception occurs during program execution.<br> For example:

	READ (1,1000) KEY=CUSTNUM$, EXCP=9999		READ (1,1000) KEY=CUSTNUM$, EXCP=9999

Badge at 23:45, 3 June 2009

2009-06-03T23:45:57Z

← Older revision		Revision as of 23:45, 3 June 2009
Line 17:		Line 17:
	READ (1,1000) KEY=CUSTNUM$, EXCP=9999		READ (1,1000) KEY=CUSTNUM$, EXCP=9999

-	In this example, a statement-label of 9999 is specified as the exception path for the READ statement. This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending. <~~b/r~~>	+	In this example, a statement-label of 9999 is specified as the exception path for the READ statement. This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending. <br>
	There are two exception branching parameters:		There are two exception branching parameters:

Badge at 23:45, 3 June 2009

2009-06-03T23:45:35Z

← Older revision		Revision as of 23:45, 3 June 2009
Line 1:		Line 1:
-
	== Exception Handling ==		== Exception Handling ==

	All input/output statements in Internet Basic allow for handling of runtime exceptions. Here are some typical examples:		All input/output statements in Internet Basic allow for handling of runtime exceptions. Here are some typical examples:
-

	*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)		*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)
Line 19:		Line 17:
	READ (1,1000) KEY=CUSTNUM$, EXCP=9999		READ (1,1000) KEY=CUSTNUM$, EXCP=9999

-	In this example, a statement-label of 9999 is specified as the exception path for the READ statement. This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending.	+	In this example, a statement-label of 9999 is specified as the exception path for the READ statement. This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending. <b/r>
	There are two exception branching parameters:		There are two exception branching parameters:

Badge: New page: == Exception Handling == All input/output statements in Internet Basic allow for handling of runtime exceptions. Here are some typical examples: *The program attempts to open a data ...

2009-06-03T23:44:39Z

New page: == Exception Handling == All input/output statements in Internet Basic allow for handling of runtime exceptions. Here are some typical examples: *The program attempts to open a data ...

New page

== Exception Handling ==

All input/output statements in Internet Basic allow for handling of runtime exceptions. Here are some typical examples:

*The program attempts to open a data file, but the file doesn't exist. (Result: Comet exception 11 -- file not found.)

* The program attempts to read a record from an existing file, but the record (and its key) does not exist. (Result: Comet exception 32 -- key not found.)

* The program attempts to read a record from an existing file, but the record is locked (extracted) by another user. (Result: Comet exception 33 -- Record Unavailable--Extract Error.)

* While reading a data record, the program attempts to read a numeric value, but the actual data field contains a non-numeric character. (Result: Comet exception 46 -- non-numeric input in a numeric field.)

* While reading through a data file in sequential (or key-sequential) order, the program reaches the last record in the file, but attempts to read one more record. (Result: Comet exception 2 -- end-of-file.)

Each of the above situations results in a Comet runtime exception. The EXCP=statement-label parameter is used to specify an "exception path" to follow if an exception occurs during program execution. For example:

READ (1,1000) KEY=CUSTNUM$, EXCP=9999

In this example, a statement-label of 9999 is specified as the exception path for the READ statement. This means that if this statement encounters an exception when it is executed, the program will branch to statement 9999, instead of abnormally ending.
There are two exception branching parameters:

EXCP=statement-label branches to statement-label
.
EXCPSUB=statement-label branches to subroutine

In any exception routine, the program may include statements to inquire into the nature of the exception. This is done with the Comet system variable named EXCP, which contains the number of the most recently encountered Comet exception.
See Comet exception messages for a complete list of runtime exceptions.

Following the example from above, an exception routine could look like this:

9999 IF EXCP=32 THEN PRINT (0) "KEY NOT FOUND" & GOTO 100
IF EXCP=33 THEN PRINT (0) "RECORD EXTRACTED" & GOTO 100

This routine, starting with the label 9999, checks the system variable EXCP for two of the most common values that might be encountered during a READ:

{| Border=1
|-
|EXCP value
|Meaning
|-
|32
|The specified key was not found in the key list
|33
|The specified key was extracted by another user
|-
|}
In an exception routine, there are several ways to deal with runtime exceptions. One way is to simply branch back to a logical starting place in the program and start over. Another is to retry the action that caused the exception. This is done with the AGAIN statement.
Another course is to instruct the program to come to an abnormal end, in the case where all possible exceptions have been tested for and handled.

For example:

9999 IF EXCP=33 THEN PRINT (0) "RECORD EXTRACTED" & AGAIN
IF EXCP=32 THEN PRINT (0) "KEY NOT FOUND" & GOTO 100
ERROR

In this exception routine, if the exception is 33, the program will display a message that the record is extracted and try the I/O statement again (as specified by the AGAIN statement). Note: This method should be used with care, as it could result in and endless loop of trying the I/O statement, testing for exception 33, trying the I/O statement, etc.
In the above routine, if exceptions 32 and 33 are not the cause, the program is instructed to take an abnormal end (the ERROR statement does this). When ERROR is encountered, the QENDITOR program will be executed and the Comet exception will be displayed on the controlling terminal.

Other exception handling statements include ERRORTO and ERRORSUB, statements that set default exception paths. Comet32 includes the NOEXCP option on file system statements so you may choose to ignore any non-fatal exception.