sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 02, 2004 3:00 pm Post subject: Exceptions |
|
|
This is what I've got so far for the Ares exception spec. It's based on discussion in the NG and may change pending Matthew's belated review.
Exception is a globally defined class similar to Object (in fact it's defined in object.d). This class is required for exception handling and all user defined exceptions are expected (but not required) to derive from it. Currently, the system throws some general exceptions, most of which employ this Exception class. The few exceptions to this rule are system errors where file and line information is provided, as these fields are not included in the Exception class. These classes may still be caught generally using Object or specifically by name but they are intentionally not derived from Exception to make recovery more deliberate. Since most of these functions are expected to not be recoverable, this should not be a problem. These exceptions are:
ArrayBoundsError
AssertError
OutOfMemoryError
SwitchError
Of the above, ArrayBoundsError and SwitchError represent unrecoverable errors. OutOfMemory may be recoverable, but any such action should be deliberate through a catch block referencing that class explicitly. AssertError is not normally recoverable, but the option is available to the careful programmer.
To increase separation between the runtime and the standard library, the above exceptions are all thrown via callbacks in [std.error]. This allows these exceptions to be defined in the standard library rather than exposed by the runtime.
Because the assert function is a built in feature of the language, it may be useful to override default behavior in some situations. This is made possible by the setAssertHandler function in [std.error]. To clear any override and return to default behavior, call this function with a null argument.
Regarding exceptin handling in general, there is something worth noting that I'm discovering are common to garbage collected languages. If an exception is thrown from a finalizer (a finally block or a class dtor) , the system just assumes the finalizer has returned and continues execution (ie. the exception is ignored). This is both to prevent accidental termination during normal exception handling and to prevent the risk of exceptions being thrown during a garbage collection run. Because of this, the chance that two exceptions may be thrown simultaneously (resulting in application termination in C++) is effectively eliminated. By same token, this restriction requires judicious use of finalizers if program correctness is to be assured.
I'd welcome any comments on the above. This is just what I've worked out so far and I'm not married to it, but I figured something was better than nothing |
|