The Right Approach to Exceptions
SeeWebsiteForEmail at erdani.org
Sun Feb 19 15:35:31 PST 2012
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
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
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.
More information about the Digitalmars-d