The Right Approach to Exceptions
Jonathan M Davis
jmdavisProg at gmx.com
Sun Feb 19 14:34:28 PST 2012
On Sunday, February 19, 2012 17:00:24 Nick Sabalausky wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
> news:jhrn3r$fie$3 at digitalmars.com...
>
> > On 2/19/12 12:49 PM, Nick Sabalausky wrote:
> >> No, exceptions need to be based around semantics, not modules.
> >
> > Packages and modules are also organized around specific areas.
>
> And those specific areas do NOT necessarily correspond 1-to-1 to error
> conditions.
>
> 1. A module can still reasonably generate more than one conceptual type of
> exception. Ex: std.file can be expected to generate both "file not found"
> and "disk full" conditions (those may both be IO exceptions, but they're
> still separate issues that are *not* always to be dealt with the same way).
> You can argue till your keyboard wears out that you don't see the
> usefulness, but the fact is, many, many, many people DO find it useful.
>
> 2. As I *already* explained in further detail, it's perfectly reasonable to
> expect one specific area to be convered by more than module.
>
> Therefore, "Modules" to "Conceptual types of exceptions" are not 1-to-1.
> They're not even 1-to-many or many-to-1. They're many-to-many. Therefore,
> module is the wrong basis for an exception.
>
> Seriously, how is this not *already* crystal-clear? I feel as if every few
> weeks you're just coming up with deliberately random shit to argue so the
> rest of us have to waste our time spelling out the obvious in insanely
> pedantic detail.
While I think that Nick is getting a bit incensed and even a bit rude in some
of his posts in this thread, I completely agree with his basic point here. In
a well-designed exception hierarchy, the exception types are based on the
types of things that went wrong. That way, you can catch them based on what
went wrong, and they can provide information specific to that type of problem.
As such, there is not necessarily any connection (let alone 1:1) betwen
exception types and modules.
You could have multiple exception types per module or have several exceptions
sharing a module. And if the exception hierarchy is done particularly well,
then code which uses Phobos will also throw those exceptions when appropriate.
For instance, in other languages, InvalidArgumentException is quite commonly
used to indicate that a function was given bad arguments when an exception is
thrown for that sort of thing - and code outside of the standard libraries
uses it for that purpose all the time.
We have as much of a connection between modules and exceptions as we do,
because Phobos is generally well-organized according to functionality, and
different functionality tends to mean different exception types. But we've also
taken it too far in some cases, creating an exception type in a module simply
because most Phobos modules have their own exceptions.
Ultimately, it's what went wrong that matters, _not_ in which module it
happened in. And if anything, we need to redesign what we have so that it
better follows that, getting rid of some exceptions, merging others, and in
some cases creating new ones. In many cases, you'll still have an exception
per module, but in some cases you'll end up with multiple, and in others,
you'll end up with none, because those modules are using exceptions from other
modules.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list