The Right Approach to Exceptions
H. S. Teoh
hsteoh at quickfur.ath.cx
Fri Feb 24 17:04:12 PST 2012
On Fri, Feb 24, 2012 at 07:37:03PM -0500, Jonathan M Davis wrote:
> On Friday, February 24, 2012 16:18:59 H. S. Teoh wrote:
> > On Fri, Feb 24, 2012 at 06:48:47PM -0500, Jonathan M Davis wrote:
> > > which, as you point out, would have to be done at runtime, or by
> > > doing something similar to what Java 7 is doing and make it so
> > > that multiple exceptions can be caught with the same block
> > >
> > > catch(Ex1, Ex2, Ex3 e)
> > >
> > > and e ends up being the most derived type that is common to them.
> > This can also be done by catch conditions by using is-expressions or
> > derived class casts, though it would be more verbose. We may not
> > need to implement both.
> You do run into the who rethrowing issue with that though, if you
> catch the wrong type. It also can force you to combine disparate catch
> blocks, since you caught the common type, and you're forced to use
> if-else statements to separate out the various cases instead of
> letting catch take care of it. All in all, it would just be _way_
> cleaner to have a way to give a list of exception types that you want
> that catch to catch.
I think you misunderstood me, what I'm referring to is this:
// MyException is common base of DerivedEx1 and DerivedEx2
catch(MyException e : cast(DerivedEx1)e !is null ||
cast(DerivedEx2)e !is null)
// catch code
There's no rethrowing necessary, the catch block doesn't execute unless
the exception is either DerivedEx1 or DerivedEx2. You also get to
specify the common base type to assign to e.
But yes, this is more verbose. I was just pointing out that it may not
be necessary to extend the language to catch multiple exception types if
we're already going to implement catch conditions.
> Also, I think that having a syntax for simply giving a list of
> exceptions that an exception block catches is plenty without needing
> the whole condition thing. The condition thing just seems like
> overkill. But maybe someone has a valid use case where giving a
> specific list of exceptions doesn't cut it.
The condition thing may be a another justification for the whole
Variant[string] thing, though, if you could do something like this:
catch(MyException e : ("myattr" in e.info) !is null)
// catch code
This then lets intermediate code on the call stack add annotations to a
passing exception, and a catch block further up the call stack to only
catch annotated exceptions.
I can't think of any actual real-world use case for this, but maybe
Jose(?), or whoever it was that wanted to add extra info to exceptions
in transit, can.
> > I don't think D's job is to stop people from doing stupid things.
> > Otherwise we might as well go back to Pascal or something. :)
> Indeed. What we need is a setup which enables (and hopefully encourages)
> people to do the right thing. We can't stop people from being stupid.
Having a proper exception hierarchy in Phobos will, in my mind, set a
good precedent to proper use of exceptions. To be quite honest, I was
shocked when I discovered the current exception-by-module situation in
Phobos---after reading TDPL I was under the impression that we had a
properly-designed exception hierarchy. :)
> For instance, much as Java generally tries to protect you from your
> own stupidity, the fact that it has very good exception hierarchy
> doesn't stop people (and in some cases the developers of its standard
> library) from doing stupid things with exceptions.
Trying to prevent stupidity often cripples the language/system. As the
old Unix adage goes:
Unix was not designed to stop people from doing stupid things,
because that would also stop them from doing clever things. --
This is one area where D trumps Java by a long shot IMO. I find Java
really straitjacketed sometimes in the way it tries to "protect" me from
myself. I have to jump through hoops to convince it that, yes, I really
*really* want to do this.
Always remember that you are unique. Just like everybody else. -- despair.com
More information about the Digitalmars-d