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

Reply via email to