DIP33: A standard exception hierarchy

[Dmitry Olshansky]

02-Apr-2013 14:37, deadalnix пишет:
> On Monday, 1 April 2013 at 11:08:16 UTC, Lars T. Kyllingstad wrote:
>> It's time to clean up this mess.
>>
>> http://wiki.dlang.org/DIP33
>
> Several things.
>
> First the usage of enums isn't the right path. This makes it hard to
> extend in general, and it is a poor man replacement for sub classes in
> general.

And using sub-classing just to tag something is equally bad. We don't 
have multiple inheritance so adding say 2 independent pieces of info can 
get devilishly hard (and lead to combinatorial explosion of classes).

What could be better is indeed "tags" that transport arbitrary set of 
interesting info about exception (that's what enums do but in more 
hard-wired way).

See also what C++ gurus come up with:
http://www.boost.org/doc/libs/1_53_0/libs/exception/doc/boost-exception.html

>
> As a rule of thumb, when you use switch in OOP code, you are likely to
> do something wrong.

And that's why? BTW D doesn't have pattern matching and type-switch like 
some OOP languages have.

You might want to add Visitor pattern to Exceptions but it's darn messy 
to deal with and is an overkill most of the time.

>
> Second, many of you error are recoverable here. It isn't quite satisfying.
>
> RangeError is a very bad thing IMO. It completely hides why the range
> fails in the first place. Trying to access front when not possible for
> instance, is an error for a reason (which is range dependent). That
> reason must be the source of the error/exception.

I/O error when in fact you just run out of range during some (bogus) 
algorithm  and that range happened to be backed by a MM-File? Think again.
>
> In general the hierarchy is weird. Why isn't NetworkingException (why
> not NetworkException ?) a subclass of IOException ?
>

No, no and no. I/O is read/write etc. calls. Network is broad stuff 
dealing at conceptually lower level (like discovering hosts that then 
would produce end-points that in turn can be connected to and only 
*then* I/O comes). "Unreachable host" is not an I/O error.

> OutOfMemoryError on its own isn't good IMO. The Error hierarchy is made
> for error that aren't recoverable (or may not be recoverable). It
> include a whole class of problem, and OOM is only one of them (another
> example is Stack overflow errors).


-- 
Dmitry Olshansky