Exception Handling

Abstract

A procedure may terminate in many ways. We may have an intentional termination caused by encountering either a return or a go to which branches out of the procedure. Or, an error may occur, such as division-by-zero or subscript-out-of-range, which causes a system interrupt which terminates execution. Or, an anticipated but rare condition may arise such as end_of_file. The return or goto mechanisms of a programming language do not allow us to handle these last two occurrences very well. On the one hand they provide no real means for the programmer to make use of the interrupt capability of the underlying machine. On the other hand it encourages awkward and inefficient programming, in the following sense. To handle anticipated errors, one typically adds a parameter to a procedure, which is appropriately set if the anticipated error is encountered. Then, a return is taken and the error flag must be queried to see if an abnormal event has occurred. An alternate approach once the error is encountered is to jump out of the procedure to an error routine, thereby disrupting the normal flow of control. Neither of these alternatives offers a powerful way to structure exception handling.

“It is human to err; it is devilish to remain willfully in error.”

-St. Augustine, Sermons No. 164, sec. 14