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
Also compare with C# Exception class
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
for chaining and C# has an "innerException" but D has only Error allows
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 original Exception somewhere. The Java/C# exception chaining solution is the "modern" way to do it: make the most general exception class chainable.

-Ben

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

"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.

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

>>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.