The Right Approach to Exceptions

[Andrei Alexandrescu]

On 2/19/12 4:20 PM, Nick Sabalausky wrote:
> "Andrei Alexandrescu"<SeeWebsiteForEmail at erdani.org>  wrote in message
>> 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.

I mentioned the issues here and there, but it's worth collecting them in 
one place.

1. Type multiplicity. Too many handwritten types are harmful. They 
exacerbate boilerplate and favor code duplication.

2. Using types and inheritance excessively to represent simple 
categorical information.

3. Forcing cross-cutting properties into a tree structure. The way I see 
exceptions is a semantic graph, and making it into a tree forces things 
like repeated catch clauses for distinct types coming from distinct 
parts of the hierarchy.

4. Front-loaded design. Very finely-grained hierarchies are built on the 
off chance someone may need something AND would want to use a type for that.

5. Unclear on the protocol. The "well-designed" phrase has come about 
often in this thread, but the specifics are rather vague.

6. Bottom-heavy base interface. Class hierarchies should have 
significant functionality at upper levels, which allows generic code to 
do significant reusable work using the base class. Instead, exceptions 
add functionality toward the bottom of the hierarchy, which encourages 
non-reusable code that deals with specifics.

There might be a couple more, but I think they can be considered derivative.


Andrei