Towards a better conceptual model of exceptions (Was: Re: The Right Approach to Exceptions)

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Feb 21 23:32:28 PST 2012


On Tue, Feb 21, 2012 at 08:56:03PM +0100, deadalnix wrote:
> Le 21/02/2012 20:00, H. S. Teoh a écrit :
[...]
> >You're right, that would be unnecessary duplication, especially since
> >an unhandled Condition becomes a thrown Exception anyway, and it's a
> >very bad idea to duplicate the entire Exception hierarchy in
> >Condition.
> >
> >Only thing is, then the handler will have to downcast the Exception
> >to get to the useful info. This may lead to messy code. But it's
> >something we should investigate.
> >
> 
> Yes, I'm aware of the problem and it is real. I have no good solution
> for it now.

I have an idea. What if handlers took *two* arguments, a Condition, and
a (possibly derived) Exception object? The raise system would then match
conditions to handlers by both the Condition type and derived Exception
type. The handler then has access to the particular derived object that
it wants to handle without needing to downcast. So it sorta simulates a
catch(DerivedException).

It's a bit harder to implement, though... we'll need to store TypeInfo
for each handler and match it up with the Condition being raised. But
I'm assuming this isn't too much more than what the runtime is already
doing with Exceptions anyway, so performance-wise it should be
acceptable.

And while we're at it, I think we should just stop pretending this is
still the same system as Lisp, and just rename Condition to
RecoveryStrategy or RecoveryOpts or something along those lines, since
that's what it is.


[...]
> >To maximize usability and minimize redundancy and bloat, I'm thinking
> >we should define categories based on what recovery actions are
> >*actually available*, rather than what actions are *potentially*
> >available. So to that end, it's not really categorization per se, but
> >more of a way of describing what recovery strategies are actually
> >available.
> >
> 
> Yes indeed. Exception should provide data about what the problem IS,
> condition on what are option to recover.

Yeah, I think it makes sense to rename Condition to RecoveryStrategy or
RecoveryOpts. The recovery choices aren't a "condition"; the Exception
object is the condition, the choices are recovery strategies.


[...]
> >Each operation should have a single condition with a well-defined set
> >of recovery methods, not some arbitrary combination of multiple
> >conditions.
> >
> >What do you think?
> >
> 
> It is exactly what lead me to create template for such cases.
> Additionnaly, thoses templates should include a way to generate the
> Exception, but I ran into a strangeness of D when exprimenting with
> and did had time to come up with something working for that. The
> condition handling and the actual operation must be separated to avoid
> code duplication and ensure separation of concerns.

Yep.


> The current design allow to create new Conditions, in the lib but also
> in user code.
> 
> If we can find a way to handle properly the Exception crazy casting
> problem we have here a very nice way to handle errors.

Would it be possible to add that second argument to handlers? I think
that will solve the problem. But it will take a bit more effort to
implement.


T

-- 
"How are you doing?" "Doing what?"


More information about the Digitalmars-d mailing list