Design exception classes

All exceptions generated by Taligent Application Environment code descend and inherit from TStandardException. This inheritance ensures sensible error message generation and allows exceptions to stream between tasks. Subclasses of TStandardException represent the actual exceptions or error conditions, and they can be further parameterized by instance variables of the specific class.

NOTE TStandardException is a very low-level class that can safely be used in primitive parts of the system, such as device drivers (assuming the specific subclasses of TStandardException do not have additional dependencies).

What to subclass

As with any interface, make the categorization client driven. The key is to think about what clients want to catch. Categories allow the clients to specify what they think they can recover. As such, introduce a broad base class only when you are sure clients want a uniform way to catch and recover from errors that descend from that base. Don't introduce a base class unless you are sure some clients want to catch and recover from errors that descend from that base in a uniform way.

Similarly, don't specialize a specific exception class unless you think that clients will take different recovery actions based on the distinction you are making. For example, TTruncatedSectorError is probably too detailed because most clients only care that a disk error occurred.

You can always record specific error causes as a data member of your exception subclass. (For example, TDiskError could have an enum member with a getter and setter, and the enum would be over possibilities like kSectorMarkMissing and kTruncatedSector.) In fact, TStandardException contains a handy integer that is intended for that purpose, and the default message formatting code uses it to select the right text. This way the end user is told precisely what the problem is.

When to subclass

There are two reasons to subclass TStandardException:

Define a category of exceptions that is handled in a unique way. With your own subclass, clients can catch only the exceptions of interest to them, perform whatever custom cleanup is appropriate, and then rethrow them for standard handling by the Application framework.

Provide scoping for the fetching of error message texts. The error text template is identified by the actual class type (a subclass of TStandardException), and an enum scoped to the subclass. Your subsystem should contain a subclass of TStandardException to which you can add your specific enum value and associated text template.


When you are designing your exception classes:

[Contents] [Previous] [Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker