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 "std.net" 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!"tango.io" 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.
Andrei
