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
