DIP33: A standard exception hierarchy

[Steven Schveighoffer]

On Mon, 01 Apr 2013 19:19:31 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Monday, April 01, 2013 19:02:52 Steven Schveighoffer wrote:

>> In general, this is not enough. Imagine having an exception type for  
>> each
>> errno number. Someone may want that!
>
> Obviously, there are limits. You don't want exceptions for absolutely  
> every
> possible error condition under the sun, but a lot of errnos are quite  
> rare and
> likely wouldn't be caught explicitly very often anyway. And something  
> like
> FileNotFoundException _would_ be caught and handled differently from  
> other file
> exceptions often enough to merit its own exception IMHO. What's being
> presented in this DIP is very sparse, and at least some portion of the  
> kinds
> should be represented by derived types in addition to the kinds.

I admit I haven't read the DIP yet, but I was responding to the general  
debate.  I agree with Lars that exceptions that add no data are hard to  
justify.

But I also hate having to duplicate catch blocks.  The issue is that class  
hierarchies are almost never expressive enough.

contrived example:

class MyException : Exception {}
class MySpecificException1 : MyException {}
class MySpecificException2 : MyException {}
class MySpecificException3 : MyException {}

try
{
    foo(); // can throw exception 1, 2, or 3 above
}
catch(MySpecificException1 ex)
{
    // code block a
}
catch(MySpecificException2 ex)
{
    // code block b
}

What if code block a and b are identical?  What if the code is long and  
complex?  Sure, I can put it in a function, but this seems superfluous and  
verbose -- exceptions are supposed to SIMPLIFY error handling, not make it  
more complex or awkward.  Basically, catching exceptions is like having an  
if statement which has no boolean operators.

Even if I wanted to write one block, and just catch MyException, then  
check the type (and this isn't pretty either), it's not exactly what I  
want -- I will still catch Exception3.  If this is the case, I'd rather  
just put an enum in MyException and things will be easier to read and  
write.

That being said, this is the mechanism we have, and the standard library  
shouldn't fight that.  I will have to read the DIP before commenting  
further on that.

-Steve