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
