www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Exception/Error chaining

reply "Ben Hinkle" <bhinkle mathworks.com> writes:
In object.d there are two classes defined

class Exception : Object
{
    char[] msg;
    this(char[] msg);
    void print();
    char[] toString();
}
class Error : Exception
{
    Error next;
    this(char[] msg);
    this(char[] msg, Error next);
}

Compare this with Java's Throwable class, which is the base class for Java 
Exceptions and Errors.
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemExceptionClassTopic.asp
The difference I'd like to point out is that Throwable has a "cause" field 

chaining. I propose that Error be deprecated and only have
class Exception : Object
{
    char[] msg;
    Exception cause;
    this(char[] msg, Exception cause = null);
    void print();
    char[] toString();
}

Why? Because currently anything that directly subclasses Exception will 
never be able to have a cause. Plus an Error will never be able to have an 
Exception as a "next". That means class authors need to be very careful 
about how they design their exceptions to either subclass Exception or 
Error. If the user of an API ever needs to throw an Exception that was 
caused by another Exception they are out of luck if they want to save that 

"modern" way to do it: make the most general exception class chainable.

-Ben
Apr 01 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d2kc50$1i3g$1 digitaldaemon.com>, Ben Hinkle says...

 I propose that Error be deprecated and only have
 class Exception : Object


I agree.  In fact, this is something I've had planned for Ares.  I don't really
see a point in having both base classes, since the user will pretty much always
want to derive from Error.


Sean
Apr 02 2005
parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Sean Kelly" <sean f4.ca> wrote in message 
news:d2n59v$14eu$1 digitaldaemon.com...

 In article <d2kc50$1i3g$1 digitaldaemon.com>, Ben Hinkle says...

 I propose that Error be deprecated and only have
 class Exception : Object


 I agree.  In fact, this is something I've had planned for Ares.  I don't 
 really
 see a point in having both base classes, since the user will pretty much 
 always
 want to derive from Error.


I can't even find any documentation mentioning Error or what the next field 
is for. It isn't used in phobos. For all I know Walter could have intended 
next to chain unrelated errors like when you are parsing a file and it has a 
bunch of syntax errors and you make a list of the errors. Given Walter's 
background I wouldn't be surprised if that is what next is for.
Anyhow, I'll see how many files would need changing or what would break in 
order to implement my proposal. I'm glad to hear that you were thinking of 
something similar for Ares.
Apr 05 2005
parent reply Sean Kelly <sean f4.ca> writes:
In article <d2u4ig$1veh$1 digitaldaemon.com>, Ben Hinkle says...

"Sean Kelly" <sean f4.ca> wrote in message 
news:d2n59v$14eu$1 digitaldaemon.com...

 In article <d2kc50$1i3g$1 digitaldaemon.com>, Ben Hinkle says...

 I propose that Error be deprecated and only have
 class Exception : Object


 I agree.  In fact, this is something I've had planned for Ares.  I don't 
 really
 see a point in having both base classes, since the user will pretty much 
 always
 want to derive from Error.


I can't even find any documentation mentioning Error or what the next field 
is for. It isn't used in phobos. For all I know Walter could have intended 
next to chain unrelated errors like when you are parsing a file and it has a 
bunch of syntax errors and you make a list of the errors. Given Walter's 
background I wouldn't be surprised if that is what next is for.
Anyhow, I'll see how many files would need changing or what would break in 
order to implement my proposal. I'm glad to hear that you were thinking of 
something similar for Ares.


One related issue I've been meaning to bring up is what I assume is a bug in the
behavior of auto classes.  That is, auto objects are not destroyed if scope is
exited from an exception being thrown.  This has one good consequence in that it
eliminates the possibility of app. termination from multiple in flight
exceptions (exceptions in finally blocks are ignored IIRC), but it violates
correct behavior IMO.

Assuming this is fixed, something would need to be done about exceptions being
thrown from destructors.  The simplest answer would be to prohibit them, but it
might be reasonable to chain them using the next pointer as well.


Sean
Apr 05 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
Anyhow, I'll see how many files would need changing or what would break in
order to implement my proposal. I'm glad to hear that you were thinking of
something similar for Ares.




I've looked a bit at phobos and probably about 10 or so FooErrors would have 
to be renamed to FooException and the subclassing changed. It's mindless 
changes but it's just so ugly to have half the exceptions FooError and half 
FooException with the split being pretty much random. User code will have to 
be updated but IMO something must be done.


 One related issue I've been meaning to bring up is what I assume is a bug 
 in the
 behavior of auto classes.  That is, auto objects are not destroyed if 
 scope is
 exited from an exception being thrown.  This has one good consequence in 
 that it
 eliminates the possibility of app. termination from multiple in flight
 exceptions (exceptions in finally blocks are ignored IIRC), but it 
 violates
 correct behavior IMO.


I think Walter recently revamped the exception handling (at least with 
'finally'). Maybe he fixed this?


 Assuming this is fixed, something would need to be done about exceptions 
 being
 thrown from destructors.  The simplest answer would be to prohibit them, 
 but it
 might be reasonable to chain them using the next pointer as well.


Luckily destructors are extremely rare in D.
Apr 06 2005