03-Apr-2013 21:43, Jonathan M Davis пишет:
On Wednesday, April 03, 2013 16:23:31 Lars T. Kyllingstad wrote:
On Wednesday, 3 April 2013 at 14:11:09 UTC, Steven Schveighoffer
wrote:
The problem I have with this whole scheme of one class per
error type is, you inevitably cannot cover everyone's use case,
so they end up having to catch a base class and then doing the
work to figure out what it is manually.
Precisely. And then, a switch over an enum is both way more
efficient and more readable than a bunch of ifs and casts.
Except that the enum solution doesn't work at all when a 3rd party needs to
add an error type to the mix,
This is the critical point. There shouldn't ever be a need to add a new
exception type to differ in a minor way. Mark you wild type as unknown
Kind of IOExcpetion is you need it.
If you want error to propagate some extra information that's a whole
other story but just subclassing everything and putting you brand name
on it doesn't scale. It doesn't help standardized error handling nor
with propagating specific info. Having million kinds (each library with
its own) to propagate this info is awful and proven to suck (see C++).
In general, I think that using error codes in exception types like you're
basically suggesting is not properly taking advantage of the language's built-
in exception features. catch is _designed_ for differentiating between errors
Between classes of Exceptions. Not between individual subtle thingies.
--
Dmitry Olshansky
