The Right Approach to Exceptions

[foobar]

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.