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