Exception handling - Introduction

Why do we need exception handling ?

Most computer hardware systems are capable of detecting certain run-time error conditions, such as floating-point overflow. Early programming languages were designed and implemented in such a way that the user program could neither detect nor attempt to deal with such errors. 

In these languages, the occurrence of such an error simply causes the program to be terminated and control to be transferred to the operating system. The typical operating system reaction to a run-time error is to display a diagnostic message, which may be meaningful and therefore useful, or highly cryptic. After displaying the message, the program is terminated.

 In the case of input and output operations, however, the situation is somewhat different. For example, a Fortran Read statement can intercept input errors and end-of-file conditions, both of which are detected by the input device hardware. In both cases, the Read statement can specify the label of some statement in the user program that deals with the condition. 

In the case of the end-of-file, it is clear that the condition is not always considered an error. In most cases, it is nothing more than a signal that one kind of processing is completed and another kind must begin. In spite of the obvious difference between end-of-file and events that are always errors, such as a failed input process, 

Fortran handles both situations with the same mechanism. Consider the following Fortran Read statement:

Read(Unit=5, Fmt=1000, Err=100, End=999) Weight

The Err clause specifies that control is to be transferred to the statement labeled 100 if an error occurs in the read operation. The End clause specifies that control is to be transferred to the statement labeled 999 if the read operation encounters the end of the file. So, Fortran uses simple branches for both input errors and end-of-file.

 There is a category of serious errors that are not detectable by hardware but can be detected by code generated by the compiler. For example, array subscript range errors are almost never detected by hardware,1 but they lead to serious errors that often are not noticed until later in the program execution. 

Detection of subscript range errors is sometimes required by the language design. For example, Java compilers usually generate code to check the correctness of every subscript expression (they do not generate such code when it can be determined at compile time that a subscript expression cannot have an out-of-range value, for example, if the subscript is a literal).

 In C, subscript ranges are not checked because the cost of such checking was (and still is) not believed to be worth the benefit of detecting such errors. In some compilers for some languages, subscript range checking can be selected (if not turned on by default) or turned off (if it is on by default) as desired in the program or in the command that executes the compiler. 

The designers of most contemporary languages have included mechanisms that allow programs to react in a standard way to certain run-time errors, as well as other program-detected unusual events. Programs may also be notified when certain events are detected by hardware or system software, so that they also can react to these events. These mechanisms are collectively called exception handling. Perhaps the most plausible reason some languages do not include exception handling is the complexity it adds to the language