DIP33: A standard exception hierarchy

[Dmitry Olshansky]

01-Apr-2013 23:46, 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.

Good. We are mostly on the same page here and later.

>
>> 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.

Okay. I guess all of this goes to "Embedded D"/"D Lite" kind of spec.

Last thing - why separating ThreadException vs ProcessException and 
should they have some base class? Just asking to see the rationale 
behind it that is missing from DIP currently.

>
>> 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.
>

Well, maybe we could just extend it later on. As it's easier to add then 
remove then let's deffer the hard ones :)

>> 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.

>
>> 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?

That's the trick - I hoped somebody will just say "aha!" and add one :)

The internal handle is hard to represent other then ... some platform 
specific integer value. There goes generality... Other then this there 
is a potential to stomp on feet of higher-level abstraction on top of 
that handle.

That last bit makes me reconsider the idea. While I see some potential 
use for it I suspect it's too niche to fit in the general hierarchy.

> Bear in
> mind that it should be general enough to cover all, or at least most,
> kinds of I/O exceptions.

Adding a Kind that states one of:
out-of-data (read empty file)
illegalOp (reading closed file, writing read-only file/socket)
interrupted (operation was canceled by OS, connection forcibly closed, 
disk ejected etc.)
hardFault (OS reports hardware failure)

...
etc. shouldn't hurt. Need to think this through better, of course, and 
consult OSes manuals again.
-- 
Dmitry Olshansky