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

New exception heirarchy

 
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: Wed Sep 21, 2005 3:08 pm    Post subject: New exception heirarchy Reply with quote

The intent behind the exception heirarchy has changed for 0.2. I'll outline the rationale below (copied from a message I wrote elsewhere) and then list the specific changes for this release:
Quote:

I was undecided on how to handle the exception heirarchy refactoring so I turned to the C++ standard for inspiration. They break it down rather simply:
Quote:

The Standard C++ library provides classes to be used to report certain errors (17.4.4.Cool in C++ programs. In
the error model reflected in these classes, errors are divided into two broad categories: logic errors and
runtime errors.

The distinguishing characteristic of logic errors is that they are due to errors in the internal logic of the program.
In theory, they are preventable.

By contrast, runtime errors are due to events beyond the scope of the program. They cannot be easily predicted
in advance.

Upon reflection, I'm coming to believe that there is some sense in the semantic value of "exception handling." That is, that exceptional situations are represented by the generation and transfer of a descriptive object (ie. an Exception) and that all such situations should be represented by an object of this type. That D provides an implicit common base class is immaterial. So while all Exceptions are Objects by identity, the medium of the exception handing mechanism is Exceptions. The only issue is how to classify them, and I think the C++ standard makes a fairly clear division in this regard. Since the existing method allows 'important' errors to be ignored by catching an Object, there is little semantic difference from ignoring errors by catching an Exception. Doing so in both cases is quite simple and represents a conscious choice by the user, be it a wise one or no.

As of 0.2, Exception is intended to be the universal base class for all exceptions, but it is not intended to be derived from directly. Instead, LogicError and RuntimeError classes have been provided for this purpose. Currently, Ares predefines four system errors:

ArrayBoundsError : LogicError
AssertError : LogicError
OutOfMemoryError : RuntimeError
SwitchError : LogicError

The D runtime may throw other exceptions (divide by zero and other trap conditions fall into this category) which will be of type Exception, but some of these may be given their own class at some point.

It is important to note that exceptions should never be caught silently and ignored, particularly at this level. Therefore, while there is no language or library-level barrier to catching and discarding all Exceptions passed through main(), doing so may leave the executing program in an undefined state.

As always, feedback is very much appreciated.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Wed Sep 21, 2005 6:26 pm    Post subject: Reply with quote

So, IOException should derive from LogicError, and be renamed IOError?

If so, then I'd support your seperation of Logic vs Runtime; though the use of the word 'Error' could happily be replaced with the word 'Exception'?

Given the latter, then IOException would become a subclass upon LogicException, and we'd all be overflowing with joy, harmony, and exceptions Smile
Back to top
View user's profile Send private message
sean



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

PostPosted: Wed Sep 21, 2005 7:00 pm    Post subject: Reply with quote

Perhaps IOException should derive from RuntimeException? My impression of most IO errors is that they aren't a result of logic problems but rather tend to occur because a network connection was lost, a disk read error occurred, etc. That aside, the semantic distance between 'Error' and 'Exception' is fairly small--I think I picked 'Error' simply because it's shorter Smile I'd have no problem with changing the common suffix to 'Exception' instead, unless someone has an objection? Perhaps std.error should be renamed to std.exception as well then?
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Wed Sep 21, 2005 7:37 pm    Post subject: Reply with quote

Yes ~ my prior post was somewhat tongue-in-cheek, but there is that thing about exceptions being called "exception" rather than something else. so, while this is in the realm of nit-picking, I think it's worthwhile trying to be consistent (unless we dare to reopen the Error vs Exception distinction again?).

And, you're right about IOException deriving from RuntimeException, although all exceptions are 'runtime' exceptions ~ there is no other kind (they don't happen to the program while it's lying dormant somewhere), so the usage of that word is somewhat overwrought and superfluous. Don't you think?
Back to top
View user's profile Send private message
sean



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

PostPosted: Thu Sep 22, 2005 12:11 am    Post subject: Reply with quote

kris wrote:
Yes ~ my prior post was somewhat tongue-in-cheek, but there is that thing about exceptions being called "exception" rather than something else. so, while this is in the realm of nit-picking, I think it's worthwhile trying to be consistent (unless we dare to reopen the Error vs Exception distinction again?).

Please no Smile As D is a systems programming language, I think it's fair to confer a good deal of control (and responsibility) to the user. The standard library is merely a toolset for achieving the user's goals in an efficient manner. If D offered some means to make exceptions non-recoverable I'd be willing to implement it as an option, but I'm not sure I'd go so far as to make non-recoverability mandatory. Perhaps that makes me a rope manufacturer, but if so I intend it to be quality rope Wink
Quote:

And, you're right about IOException deriving from RuntimeException, although all exceptions are 'runtime' exceptions ~ there is no other kind (they don't happen to the program while it's lying dormant somewhere), so the usage of that word is somewhat overwrought and superfluous. Don't you think?

SystemException perhaps? I kind of like the idea of being able to identify logic errors separately from external failures, for reporting purposes if nothing else (perhaps save a stack trace for logic errors but not system errors, etc).
Back to top
View user's profile Send private message
sean



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

PostPosted: Thu Sep 22, 2005 6:25 pm    Post subject: Reply with quote

Bah, I'm back and forth on having the Logic and System exception classes. I like them in theory, but it raises odd issues like how to handle packages that use a single base exception class to represent all exceptions thrown from that library. Most would probably be logic errors, but certainly not all (Mango being a good example). I'll go review all the past talk on exception heirarchies and see if I can find an alternate design to consider as well. Though whatever happens, Exception will remain a common base class. No more using Object for that purpose.

[edit]

It looks like the alternate idea is to classify exceptions by package rather than by type. This is how I've always used them in the past, so perhaps it makes sense here too. The lack of multiple inheritance kind of forces us to choose one method or ther other, so.... maybe I'll sleep on it Smile I suppose if the Logic/System approach were more popular people would actually use these base classes in C++ as well (I've never met anyone who does), and perhaps the lack of MI is the kicker.
Back to top
View user's profile Send private message
sean



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

PostPosted: Mon Oct 17, 2005 12:46 pm    Post subject: Reply with quote

Done. std.error has been renamed to std.exception to bring it more in line with the new naming convention. RuntimeError and LogicError have been removed--while they were a nice idea I had trouble differentiating between the two in many cases. All exception classes have had their suffic changed from 'Error' to 'Exception', they now derive from Exception directly as well. A SystemException may be added as their parent at some point, but it's not there yet.
Back to top
View user's profile Send private message
sean



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

PostPosted: Fri Oct 21, 2005 12:05 pm    Post subject: Reply with quote

I made a mistake in the update--std.exception still has "std.error" as its module name. This will be fixed in the next release.
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