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
