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