FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Exceptions

 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 02, 2004 3:00 pm    Post subject: Exceptions Reply with quote

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 Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group