The Right Approach to Exceptions

[Jonathan M Davis]

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