It may be asked if there is a solid link between object-oriented programming and exception handling. I see two solid object-oriented contributions to error handling. The contributions are (1) representation of an error as an object, and (2) classification of errors in class inheritance hierarchies. These contributions will be explained at an overall level in this chapter. In Chapter 36 we will address the same issues relative to C#.

35.1 Errors as Objects 35.2 Classification of Errors

 

35.1.  Errors as Objects
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

An error is characterized by several pieces of information. It is attractive to keep these informations together. By keeping relevant error information together it becomes easier to propagate error information from one place in a program to another.

Seen in this light, it is obvious that an error should be represented as an object.

Encapsulation of relevant error knowledge Place of occurrence (class, method, line number) Kind of error Error message formulation Call stack information Transportation of the error From the place of origin to the place of handling Via a special throw mechanism in the language

An error is an object. Objects are instances of classes. Therefore there will exist classes that describe common properties of errors. In the next section we will discuss the organization of these classes in a class hierarchy.

35.2.  Classification of Errors
Contents   Up Previous Next   Slide Annotated slide Aggregated slides    Subject index Program index Exercise index 

There are many kinds of errors: Fatal errors, non-fatal errors, system errors, application errors, arithmetic errors, IO errors, software errors, hardware errors, etc. It would be very helpful if we could bring order into this mess.

In Section 35.1 we realized that a concrete error can be represented as an instance of a class, and consequently that we can deal with types of errors. Like other types, different types of errors can therefore be organized in type hierarchies. At the programming language level we can define a set of error/classes, and we can organize these in an inheritance hierarchy.

Figure 35.1 shows an outline of type hierarchy for different kinds of errors. The concrete C# counterpart to this figure is discussed in Section 36.4.

Figure 35.1    A sample error classification hierarchy

As hinted by the introductory words of this section, there may be several different classifications of errors. The classification in Figure 35.1 only represents one such possibility. If multiple inheritance is available (see Section 27.4 and Section 27.5) multiple error classification schemes may coexist.