On Sunday, 19 February 2012 at 20:57:09 UTC, 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.
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
I just died a little reading this.
Are you suggesting that in order to handle IO exceptions I need
to:
try {
...whatever...
} catch (PackageException!"std.io") {...}
} catch (PackageException!"tango.io") {...}
} catch (PackageException!"otherLib.io") {...}
...
What the hell is wrong with just using an IOException?
AS Nick wrote, it seems you have a complete lack of understanding
of how exceptions work which is unsurprising coming from a c++
expert.
Also, this entire discussion you started about "improving"
exceptions looks to me like a combination of NIH syndrome
sparkled with heavy doses of premature optimization.
