DIP33: A standard exception hierarchy

[Dmitry Olshansky]

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