The Right Approach to Exceptions

[H. S. Teoh]

On Mon, Feb 20, 2012 at 08:53:24PM +0100, deadalnix wrote:
[...]
> So if I sum up things a bit (and refactor the design a bit according
> to what is best as I understand it) :
> 
> 1/ lib don't throw exception, they raise a Condition.
> 
> 2/ If an handler exists for that condition, then the handler is
> called, and the condition is passed as parameter. The condition
> provide an interface so the handler can specify how to handle that
> condition.
> 
> 3/ The condition provide a way to throw in its interface. This part
> of the interface of Condition.
> 
> 4/ If no handler is found, the throw method of the Condition is called.
> 
> 5/ The handler is provided in a scoped manner.

Looks good.


> 6/ This mecanism is provided as a lib.

Not necessarily; it would be nice to have language support. But at least
it's implementable as a lib (as I've shown), so we don't have to invest
the time and effort to implement language support until we're sure it's
a good idea, after thorough testing with the lib.


> 7/ The mecanism is provided as a richer way to use Exceptions.
> 
> Is it a solid base to start on ? I seems we need to start working on
> std.condition ;) BTW, do we need language support to implement that ?
> I don't think so, but I'm quite new to the issue.

I'm not sure yet, but probably language support is be needed to reduce
the amount of syntax you need to write just to define Conditions. Unless
we can figure out a clever way of using templates or mixins or some such
to make it easier to write.

Ideally, you'd want to declare Conditions inside the catch block of the
function, instead of making a separate class definition outside. But I'm
not sure how to make such a thing work if the handler needs to know what
methods are available in the first place. Perhaps a compromise is to use
some templates with mixins to generate code for the Condition subclass
and for the custom catch block for handling recovery strategies.

Also, another issue that's still unclear to me is, if no handler is
found and the Condition gets thrown, does it still make sense to throw
the Condition object? Because once the stack unwinds, the recovery
methods are probably no longer meaningful. Also, the fact that no
handler was found means that no handler will ever be found, so the stack
will just unwind to a catch block. And it's doubtful that at that level,
the recovery options encoded in the Condition are usable at all.

So some parts of this system need some rethinking.


T

-- 
Don't modify spaghetti code unless you can eat the consequences.