View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Sep 21, 2005 3:08 pm Post subject: New exception heirarchy |
|
|
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 |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Sep 21, 2005 6:26 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Sep 21, 2005 7:00 pm Post subject: |
|
|
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 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 |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Wed Sep 21, 2005 7:37 pm Post subject: |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Sep 22, 2005 12:11 am Post subject: |
|
|
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 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
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Sep 22, 2005 6:25 pm Post subject: |
|
|
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 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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Mon Oct 17, 2005 12:46 pm Post subject: |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Fri Oct 21, 2005 12:05 pm Post subject: |
|
|
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 |
|
|
|
|
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
|