The Right Approach to Exceptions

Andrei Alexandrescu SeeWebsiteForEmail at
Sun Feb 19 12:57:08 PST 2012

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.

> For example, if I want to do something upon a network error, minimum 99
> times out of 100 I don't give a shit if it came from libNetworkFoo or
> libNetworkBar, and I don't *want* to care. What I care is whether or not
> there was a "network" error and possibly what *conceptual* type of network
> error.

Then it wouldn't help if each defined its own hierarchy.

The way I see it is, a "well-designed" package and module hierarchy 
would naturally engender a "well-designed" exception hierarchy. This is 
because packages and modules are organized on functional areas, so e.g. 
there is an "" package that has its own exception types etc. 
There would be some special cases indeed (e.g. a module initiating an 
exception defined in another), so it's good those are possible too. I 
want to automate the common case.

> Furthurmore, what if I change some implementation detail to use a different
> module? Then I have to go changing all my catch blocks even though it's
> conceptually the same fucking error handled the same way.

That is an issue regardless. Occasional exception translation is a fact 
of life.

> However, I wouldn't object to the idea of an "originatingModule" member
> being added to Exception that's automatically filled by the runtime (perhaps
> lazily). Although really, I think what would be more useful that that would
> be "Does xxx module/package exist in the portion of the callstack that's
> been unwound?"

That's why PackageException!"" inherits 
PackageException!"tango". That's all automatic. Essentially there's 1:1 
correspondence between package/module hierarchy and exception hierarchy.

> As far as "when to add or not add an exception class", it's perfectly
> reasonable to err on the side of too many: If there's an unnecessary class,
> you can just ignore it. Problem solved. If there's a missing exception
> class, you're shit out of luck. Case closed.

I disagree that having too many exception types comes at no cost.

> I can't shake the feeling that we're desperately trying to reinvent the
> wheel here. The round wheel is solid technology with a proven track record,
> we don't need to waste time evaluating all these square and oval wheels just
> for the fuck of it.

The wheel is not round. We just got used to thinking it is. Exceptions 
are wanting and it's possible and desirable to improve them.


More information about the Digitalmars-d mailing list