DIP33: A standard exception hierarchy

[H. S. Teoh]

On Mon, Apr 01, 2013 at 01:08:15PM +0200, Lars T. Kyllingstad wrote:
> It's time to clean up this mess.
> 
> http://wiki.dlang.org/DIP33

I'd prefer "NetworkException" instead of "NetworkingException" (long
name with no added advantage).

About the use of enums in FilesystemException, NetworkingException,
etc.: I understand the rationale for them, but this also makes them
closed for extension. Is there anything fundamentally wrong with
creating subclasses of these exceptions instead of attempting to cover
*all* possible problems in a single enum?

I like the use of chaining to attach errno or windows system errors to
exceptions. This solves the problem of errno's not being easily mapped
to one of the standard exception classes. It's sort of the reverse of
what chaining was intended for (another exception being thrown while the
first one was in transit), but I haven't actually seen any real use case
for the latter, so we might as well use it for the purpose here.

The only thing is, this makes library code a bit trickier to write.
Maybe Phobos needs to provide some kind of standard (though
system-specific) way of mapping errno, windows error codes, etc., into
one of the standard exception types, so that this mapping won't have to
be duplicated all over the place. Obviously it can't be completely
automatic, since some errno's may map to different exceptions depending
on context, but *some* amount of mapping would be highly desirable to
avoid code duplication.

Another nice thing to have (not sure how practical it will be) is to add
more information to the exceptions under Exception. To truly free us
from the tendency to just invent GetoptException, XMLException,
RegexException, etc., we need to consider that sometimes you *do* want
to know where the exception came from. For example, you could be calling
std.getopt from some generic initialization code that does other stuff
too, both of which may throw a ConversionException, say. Sometimes you
need to distinguish between them (display a command-line syntax help in
one case, just display an error in the other case, depending on where
the exception came from). One solution is to add a locus field to
Exception:

	class Exception : Error {
		...
		/// Where this exception came from
		/// E.g., "std.getopt", "std.xml",
		/// "my.program.init.complexconv", etc..
		string locus;
	}

This way the catching code doesn't have to downcast, guess, or do some
ugly non-portable hacking to figure out what to do.

This field should probably be automatically filled by Exception's ctor,
so that it doesn't require additional burden on the programmer.

I'm not 100% sure the module name should be used in this field, but the
idea is that it should contain some way of identifying the origin of the
exception that can be programmatically identified.


T

-- 
Two wrongs don't make a right; but three rights do make a left...