DIP33: A standard exception hierarchy

[Lars T. Kyllingstad]

On Monday, 1 April 2013 at 21:39:18 UTC, Dmitry Olshansky wrote:
> 01-Apr-2013 23:46, Lars T. Kyllingstad пишет:
>> On Monday, 1 April 2013 at 18:40:48 UTC, Dmitry Olshansky 
>> wrote:
>>> 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.

Well, I hadn't even considered that the same exception could be 
used for both.  I see the similarity between processes and 
threads, but I also think there is a difference in how/when/where 
you want to deal with errors related to them.  Say you have a 
function that starts a new process and then spawns a new thread 
to monitor it, and then the function fails for some reason.  This 
could be something you'd want to deal with on different levels, 
as a ProcessException could simply be that you got the wrong 
executable name, while a ThreadException would usually point to a 
much deeper issue.


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

I have thought some more about it, and a basic serial comms error 
should probably be an IOException.  An error in a higher-level 
serial protocol, on the other hand, would be a NetworkException, 
and then the name doesn't suck so much.  CommException may still 
be better though, or maybe ProtocolException.

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

These are good suggestions, and seem general enough.

Lars