DIP33: A standard exception hierarchy
Dmitry Olshansky
dmitry.olsh at gmail.com
Mon Apr 1 11:40:40 PDT 2013
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?
2. ProcessException is IMHO a system exception. Plus some RTOses systems
may not have processes in the usaul POSIX sense. It needs some thought.
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.
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.
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?
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.
7. DocParseExcpetion ---> TextParseException there is a notion of a
binary "document" (e.g. BSON databases like Mongo DB).
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.
That's it so far. We'll see if there is more ;)
--
Dmitry Olshansky
More information about the Digitalmars-d
mailing list