The Right Approach to Exceptions
Nick Sabalausky
a at a.a
Sun Feb 19 14:20:03 PST 2012
"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message
news:jhrnn5$h1l$1 at digitalmars.com...
> 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.
>
Right, and yet that's exactly what your suggestion of tying exceptions to
modules would imply.
>> 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.
>
You're suggestion exacerbates the problem for no user benefit. This isn't
the first time you've tried to push a negligably-time-saving scheme into
Phobos at the expense of user code.
> 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.
>
But there *isn't* a 1:1 correspondence. A "file not found" is damn "file not
found" no matter what lib you're using: phobos, tango, fooBarFileLib,
what-the-hell-ever. You're "1:1" pretends that a non-existent file is
somehow different from one lib to another.
>> 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.
>
Jesus christ. You pull out the pedantic "that's not a perfectly-stated
argument" whacking stick at every opportunity, and yet you yourself put
forth arguments like "I disagree"? What the fuck?
>> 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.
>
They're wanting? What's the problem with them? I see no problem, and I
haven't seen you state any real problem.
More information about the Digitalmars-d
mailing list