DIP33: A standard exception hierarchy

[Lars T. Kyllingstad]

On Monday, 1 April 2013 at 18:40:48 UTC, Dmitry Olshansky wrote:
> 01-Apr-2013 15:08, Lars T. Kyllingstad пишет:
>> It's time to clean up this mess.
>>
>> http://wiki.dlang.org/DIP33
>
> Overall neat.
>
> 1. Where to define this hierarchy.
> Captain the obvious says std.exception, but can we fit all of 
> them there?

Some of them have to be in core.exception.  Personally, I think 
the rest of the base hierarchy should be in std.exception.  In 
fact, I think the "standard hierarchy" should be defined as 
"what's in core.exception and std.exception".

If we identify cases where modules absolutely *must* extend these 
classes for extremely specific purposes, this can be done within 
the module.

> 2. ProcessException is IMHO a system exception. Plus some 
> RTOses systems may not have processes in the usaul POSIX sense. 
> It needs some thought.

Well, I *don't* think ProcessException is a SystemException. :)  
And if druntime/Phobos is to be used on OSes that don't have 
processes, there are other adaptations that have to be made that 
are probably more fundamental.


> 3. I assume that NetworkingException should rather be 
> NetworkException. Not only that but I truly hope it deals with 
> network-only events (like resolver errors, host unreachable 
> etc.) not with normal I/O Exceptions happening on sockets. It 
> could get tricky to separate the two on some OSes.

I have changed the name.  I have the same view of the 
NetworkException/IOException separation as you.

> 4. A quiz as an extension of 3 - where a e.g. serial port 
> exceptions would fit in this hierarchy? Including Parity 
> errors, data overrun etc.
> Let's think a bit ahead and pick names wisely.
> Maybe turn NetworkException --> Comm(unication)Exception, I 
> dunno.

Good question, I dunno either. :)  I agree we should think about 
it.


> 5. Continuing the above - a failed call (in-system) of a 
> general purpose IPC library would be a ... SystemException? A 
> network exception? Should it matter to the user?

Note that I am only saying that the standard exceptions should 
cover *most* error categories.  100% is not feasible, and we 
shouldn't even try.  This may be one of the exceptions (haha) to 
the rule.

> 6. I like ParseException. Wondering if could be generalized a 
> bit - in a sense it's a "bad format"/"malformed" exception. For 
> instance corrupt DB file reporting ParseException (= bad 
> format) is rather wacky.

I agree, and welcome all suggestions for better names.


> 7. DocParseExcpetion ---> TextParseException there is a notion 
> of a binary "document" (e.g. BSON databases like Mongo DB).

Agreed.


> 8. For IOExcpetion we might consider adding an indication on 
> which file handle the problem happened and/or if it's 
> closed/invalid/"mostly fine" that.

Which form do you suggest that such an indicator should take? 
Bear in mind that it should be general enough to cover all, or at 
least most, kinds of I/O exceptions.

Lars