Exception Handler Magic
Fall 1996
The use of exception handlers might be considered an ADVANCED topic that is really beyond the scope of this course and others! However, should you dare try to enter this mysterious world, this document will give you a bit of an introduction into what you are getting into. The reference manual is really written for someone who knows what they are looking for so do not feel bad if it seems unintelligible!
Note that the handler concept can only be found in the Turing Reference manual, 4th edition and later. If you have an earlier version, just get a look at the two pages in a newer manual. However, it is most likely that the explanation below will help you the most! In the 4th edition, look under exceptionHandler and in later editions, look under handler.
Exception handlers are a way to catch the errors that cause your program to terminate. They can also be used to handle other exceptions that indicate some sort of behaviour that is not in the normal flow of the program or algorithm. For our purposes, assume that the exception handler is dealing with some sort of error condition caused during the execution of your program, such as a division by zero. The way that exceptions are handled is generally language, hardware, and operating system dependent.
The execution of an application program is under the supervision of the operating system, so when an error is encountered the operating system will take over and usually cause the program to terminate, sometimes with a meaningful error message. To catch an error means that when the error is detected, control is maintained by the application program, rather than letting the operating system abort the execution. This allows the application to handle the error condition in a more graceful manner.
When an error first occurs, control of execution will jump to a low-level exception routine that will determine the error and possibly do some cleanup so that bad things do not continue to happen. When the exception routine completes, it generates an exception number, which is used as a way to communicate what type of error occurred. Control is then returned to the operating system, which would normally terminate the application program, or to a user-defined exception handler, if one exists. The user-defined handler also has access to the exception number as a way for it to decide what action to take.
To use handlers in Turing, consider this example (click here).
This program will read in two numbers, divide them and give you the result. To exit the program, enter two zeroes. The division is done in the function called Divide.
The handler routine is defined as the first thing in the definition of the function. When an error occurs during the normal execution of the function, the low-level routine will jump to the handler routine, passing it one argument, which is the exception number. The user can then code into the handler routine the appropriate action depending on the value of the exception number. To do this, the user will need to know the correspondence between the type of error and the exception number that is returned. This correspondence is often system dependent. In our installation, the exception number for division by zero is symbolically defined as excpDivOrModByZero. The handler in the example first checks what the exception number is and if it is for a division by zero, then it outputs an error message. The else clause is unlikely to happen, but is included just in case! Inside the else clause is a quit statement. When this is encountered, the program terminates at that point, so in this example, all exceptions, other than division by zero, will cause the program to print Error and then stop.
Once the handler routine is invoked, it essentially replaces the actions that would have happened in the procedure after the error occurred. Since this handler is included inside a function, it must have a result statement and return a value, exactly as if the function had terminated normally. A handler inside of a procedure will return back to the calling routine. In the example, the handler just returns a zero after printing the error message.
To do the optional part of Assignment #3, you will need to know the exception number for errors on improper input when using the get command. The error is called excpGetItemIllegal.
You can look at the other exception numbers by going to the %oot directory under Chdir in the Directory Viewer. Then go to predefs/modules and look at the file Excepts. Now you are on your own. Do not ask me what they all mean!