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
