DIP33: A standard exception hierarchy

[Lars T. Kyllingstad]

On Monday, 1 April 2013 at 17:28:11 UTC, H. S. Teoh wrote:
> 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).

Agreed.  I have changed it now.


> 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?

Phobos/druntime devs will have the opportunity to add enum fields 
to cover every error category in those libraries, and the users 
themselves can still extend the classes the "normal" way.  As you 
may have noticed, the first member of each enum is "unknown", 
which is meant for errors that do not fall into any of the other 
categories.  (There may be a better name for this, like "other", 
and maybe there should be a separate enum member called 
"userDefined"?)

My problem with subclasses is that they are a rather heavyweight 
addition to an API.  If they bring no substance (such as extra 
data), I think they are best avoided.


> 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.

This is a good idea.


> 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.

My first though was: "Isn't this what the stack trace is for?", 
but then again, that's rather bothersome to parse 
programmatically.  I'm not completely sold on the idea of tagging 
exceptions with their modules of origin, but I don't have any 
good alternatives, either.

Lars