On Mon, 01 Apr 2013 19:19:31 -0400, Jonathan M Davis <[email protected]>
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
