The Right Approach to Exceptions

[Jonathan M Davis]

On Sunday, February 19, 2012 14:57:08 Andrei Alexandrescu wrote:
> On 2/19/12 1:19 PM, Nick Sabalausky wrote:
> > That wouldn't be as useful. What the catcher is typically interested in is
> > *what* happened, not *where* it happened.
> 
> But module organization is partitioned by functional areas.

Yes and no. That's mostly true in something like the standard library, but it 
begins to blur even there. For instance, what if a function ends up doing some 
unicode related stuff internally (probably as an optimization for string or 
somesuch) and ends up needs an enforce for something related to that. What's 
it going to throw? It should throw a UTFException. But the function itself 
could be in a completely different module than std.utf. _Most_ of the stuff that 
deals with unicode in a manner that would require throwing a UTFExcepton is in 
std.utf, but that doesn't mean that it all is.

And if someone is writing code outside of Phobos, it could be that a Phobos 
exception is the best one to use - in fact with a really well designed 
exception hierarchy, that's often what's supposed to happen. Maybe they're 
doing something file-related and a FileException makes good sense. Then they 
should use that.

In none of these cases does the module have anything to do with the exception 
type. Because most modules in Phobos _are_ organized by functionality, the 
exceptions tend to be done on a per module basis, but that's not really where 
the focus should be, and in some cases, we've taken it too far, making 
exception types specifically for a module, because we're giving each module its 
own exception type rather than because that module happens to encompass a 
particular type of functionality that merits a specific exception type.

So, the focus needs to be on the type of exception, not where it came from. 
Having exception-handling code care about which module an exception came from 
would just be increasing coupling to no real benfit IMHO. It may be useful to 
the programmer, but not the program, and the stack trace should already have 
it.

- Jonathan M Davis