The Right Approach to Exceptions

[deadalnix]

Le 20/02/2012 06:57, H. S. Teoh a écrit :
> On Sun, Feb 19, 2012 at 09:12:25PM -0600, Andrei Alexandrescu wrote:
>> On 2/19/12 8:52 PM, H. S. Teoh wrote:
> [...]
>>> Correct, so that would be a recovery strategy at the operation level,
>>> say at sendHttpRequest or something like that. There is not enough
>>> information available to sendHttpRequest to know whether or not the
>>> caller wants the request to be retried if it fails.
>>>
>>> But if the higher-level code could indicate this by way of a recovery
>>> policy delegate, then this retry can be done at the sendHttpRequest
>>> level, instead of percolating up the call stack all the way to
>>> submitHttpForm, which then has to reparse user data, convert into
>>> JSON, say, and then retry the entire operation all over again.
>>>
>>> I'm really liking the Lisp approach.
>>
>> Now we're talking. Ideas. Outside the box.
> [...]
>
> 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.
>
> This implementation is more to demonstrate the *semantics* of such a
> system, rather than a sample code of the real thing. Before anyone jumps
> on me for writing very bad code. ;-)
>
> In a real implementation, I probably wouldn't inherit Condition from
> Exception, for example. A real implementation would have language-level
> support for declaring recovery strategies within the function that
> handles them, rather than the kludge of declaring them separately and
> abusing the exception system to handle recovery actions.
>
> Also, registered handlers would need to be cleaned up upon scope exit,
> so that they don't cause crazy side-effects in unrelated code later on
> in the program.
>
> But anyway. The point of this code is to demonstrate:
>
> (1) How an exception generated in low-level code is recovered within the
> low-level code without unwinding the stack all the way back to the
> top-level caller;
>
> (2) How the top-level caller can provide a delegate that makes decisions
> that only the top-level code is qualified to make, yet does so in the
> context of low-level code so that recovery can proceed without unwinding
> the stack any more than necessary.
>
> I deliberately made the delegate prompt the user for a fixed filename,
> even allowing the option of aborting if the user wants to give up. This
> is to show how the system handles different recovery actions. This, of
> course, isn't the only way to do things; you can programmatically decide
> on a recovery strategy instead of prompting the user, for example.
>
> What do y'all think?
>
>
> T
>

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.

Isn't a retry function provided by phobos and a transeient property as 
proposed by Andrei a better alternative ?