The Right Approach to Exceptions

[deadalnix]

Le 20/02/2012 19:53, H. S. Teoh a écrit :
> On Mon, Feb 20, 2012 at 06:37:07PM +0100, deadalnix wrote:
>> Le 20/02/2012 06:57, H. S. Teoh a écrit :
> [...]
>>> Alright. This thread has gone on for too long with lots of talk but
>>> no down-to-earth, real code. So I decided to code up a quick-n-dirty
>>> proof-of-concept implementation of a Lispian scheme of exception
>>> handling. The source files are attached.
> [...]
>> I read your code with great interest ! I'm not sure about this. This
>> is a lot of code to not achieve that much. OK, the stack hasn't been
>> destroyed, but your delegate has its own scope and cannot do a lot.
>
> The delegate has full access to the scope of main(), or wherever it was
> registered from, which the low-level error recovery code has no access
> to.
>
>
>> Isn't a retry function provided by phobos and a transeient property as
>> proposed by Andrei a better alternative ?
>
> The problem is that by the time you regain control at the catch, the
> stack has already unwound to main(), so if you need to retry, you need
> to call openDataFile() all over again.
>
> In this case it's not too bad, because openDataFile() is very simple.
> But imagine if this openDataFile() was nested deeply inside a few layers
> of functions called from main(), then by the time you unwind the stack
> to main(), all the previous work done is lost, and you have to restart
> from the beginning.
>
> Also, how does the transient property help main() know that it should
> prompt the user for a different filename? What if a different exception
> was caught, like NetworkDriveUnreachable? It wouldn't make sense to
> prompt the user for another filename in this case.
>
>
> T
>

Yes, I see the point. This has clearly some advantages.

Considering the handler, This would be great to see it as scoped. This 
imply using a scope delegate, and probably something as RAII to create 
it and delete it when we go out of scope.

I'm more doubtfull about what can be done on the throw side. This need 
to be refined, and to be honnest, the idea is too new in my head to come 
up with something significant. The concept needs some decantation.

I wonder however, how to do something clean. The delegate will need some 
knowledge of the thrower onternal to do something really usefull, but 
then, we make the codebase more fragile (because the caler will depend 
on implementation of the calee, something that we want to avoid).