On Tue, 2011-11-01 at 10:06 +1300, Greg Ewing wrote:
Ron Adam wrote:
If we put some strict requirements on the idea.
1. Only have a *SINGLE* exception type as being resumable. 2. That exception should *NEVER* occur naturally. 3. Only allow continuing after it's *EXPLICITLY RAISED* by a raised statement.
All of the problem issues go away with those requirements in place, and you only have the issue of how to actually write the patch. Earlier discussions indicated, it might not be that hard to do.
I'm not familiar with these earlier discussions. Did they go as far as sketching a feasible implementation? It's all very well to propose things like this, but the devil is very much in the details.
Yeah, there isn't very much about the details, but I think it is worth looking into as it would pretty much does exactly what is needed. (IMHO)
Here is some of the things I was able to find. But as I said, the discussions didn't get very far. I'm hoping that the idea has more merit in the smaller 'restricted' context of coroutines rather than for general exception handling.
Here is a very old 1994 thread that is interesting reading. (Long but worth while.)
There was a reference to allow 'raise' to send out a reference, rather than an exception. That may be an interesting way to do this.
Some more that didn't go anywhere...
I can't seem to find where I found the "It wouldn't be too hard to do part.". But if a final restriction of only working with generators at first is added, it may make it easier as they can already be suspended.
Here is a python implementation for lisp style restarts. I haven't studied it yet, but it may show a way. (I'm going to look at this in more detail tonight.)
Not sure if these would help, but they may be of interest on a more theoretical level.
Wikipedia has this on it's exception handling page ...
""" Restarts separate mechanism from policy
Condition handling moreover provides a separation of mechanism from policy. Restarts provide various possible mechanisms for recovering from error, but do not select which mechanism is appropriate in a given situation. That is the province of the condition handler, which (since it is located in higher-level code) has access to a broader view. """
In the case of coroutines, the error's are the suspension points, and the error handler is the scheduler that switches between them. The context is a bit different but I believe the concept is still applicable.
Hope some of this is helpful.