Conclusions of the exception discussion

[Jonathan M Davis]

On Saturday, February 25, 2012 07:29:01 Kevin Cox wrote:
> I think there should also be multiple catches so that you can deal with
> different exceptions different ways without trying to upcast them over and
> over again.

You can do that now. Just catch each specific exception type that you want to 
catch. The issue is when you want to catch a specific set of exceptions and 
treat them all the same, but you don't want to treat all exceptions of their 
common type the same.

catch(e : UTFException, UnicodeException)
{
}
catch(StringException e)
{
}
catch(Exception e)
{
}

Presently, the only common type that UTFException and UnicodeException share 
is Exception. So, if we didn't have a syntax like I use above (which we 
currently don't have), if either have to catch UTFException and 
UnicodeException separately and duplicate the code within the catch block for 
each of them (though you could use a mixin or a function to reduce the 
duplication), or you'd have to catch Exception, and then do something like

catch(Exception e)
{
    if(cast(UTFException)e || cast(UnicodeException)e)
    {
    }
    else if(cast(StringException)e)
    {
    }
    else
    {
    }
}

That's far uglier and is completely unable to take advantage of catch's 
ability to catch by type. Also, what if you didn't really want to catch 
Exception? e.g.

catch(e : UTFException, UnicodeException)
{
}
catch(StringException e)
{
}

Then, if you went to catch Exception, because it was the common type, you'd 
have to rethrow the exception if it wasn't one of the 3 that you cared about, 
which resets the stack trace.

_That_ is the problem that this is trying to solve. If you really want to 
catch exceptions individulally by their specific types, then you can already do 
that just fine.

- Jonathan M Davis