DIP33: A standard exception hierarchy

[Jacob Carlborg]

On 2013-04-02 01:52, Steven Schveighoffer wrote:

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

The obvious solution to that would be to be able to specify multiple 
exception types for a single catch block:

catch (MySpecificException1, MySpecificException2 ex)
{
}

-- 
/Jacob Carlborg