Re: About exception handling again ...

[Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>]

Hello John!


On 8/3/20 6:41 AM, John Cowan wrote:
>
>
> On Sun, Aug 2, 2020 at 2:05 PM Zelphir Kaltstahl
> <zelphirkaltstahl@posteo.de <mailto:zelphirkaltstahl@posteo.de>> wrote:
>  
>
>     1. Is there any situation, in which one would like to raise a
>     non-continuable exception / condition, and not unwind the stack? Would
>     that make sense in any situation?
>
>
> I'm going to talk about Scheme in general, not Guile specifically. 
> There are at least three use cases:
>
> 1) A reflective low-level debugger that can examine variables in the
> current stack frame, which can't possibly work if the stack frame is gone.
>
> 2) A handler that wants to examine the dynamic environment in place
> when the exception was raised.
>
> 3) A restart system that returns to the context of the raise and
> executes recovery code, often chosen on the basis of interaction. 
> Frequently used recovery actions include retrying the failed operation
> (on the assumption that the external environment has changed),
> retrying the operation with one or more different variables, and
> setting local variables to new values and retrying.
>
> A "Lisp debugger" is code that examines the available restarts and
> invokes one of them, but Scheme doesn't have such a thing yet because
> it has no restart system yet.  See
> <https://github.com/johnwcowan/r7rs-work/blob/master/RestartsCowan.md>. 
> CL has a restart system rather more complex than my proposal, which is
> based on an earlier proposal by Taylor Campbell.
>  
>
>     Is this all correct?
>
>
> I would say "correct but not complete".
>  
>
>     3. What would be a code example for a continuable exception /
>     condition
>     and what does the "continuing" there look like? I think the idea of
>     exception in my head is still influenced a lot by Python or other
>     languages, where it seems like all exceptions are non-continuable. (Is
>     that correct?)
>
>
> Let's say a procedure wants to open a configuration file, but the
> configuration file cannot be opened.  Raising a continuable exception
> allows the handler to take some recovery action (perhaps it prompts
> the user for the location of the config file) and return to the point
> where the exception was raised.  Restarts extend this concept by
> providing a protocol for the handler to communicate with the raiser,
> just as condition objects are a protocol to let the raiser communicate
> with the handler.
>
> In languages without continuable exceptions, such a retry must be done
> from the handler level, which may imply re-executing a lot of code
> that was run before the config file was wanted.  With continuable
> exceptions, this is not necessary.
>
> The `guard` special form basically emulates the behavior of {Python,
> JS, Java, C#} style exception systems in cases where that behavior is
> sufficient.
>  
>
>     4. Is there a situation, where one would like to raise a continuable
>     exception / condition, but also unwind the stack?
>
>
> Not that I can think of.
>  
>
>     IWhat does it mean for with-exception-handler to "return"? How can
>     it not
>     return? Does this mean CPS like not returning, or does it mean "not
>     return a value"?
>
>
> The former.  An exception being raised non-continuably is really
> raised continuably, but then if that returns, an exception that means
> "attempt to continue from a non-continuable exception" is raised
> non-continuably.  If you aren't careful in your handler to re-raise
> exceptions you don't understand (normally with raise-continuable),
> this will obviously get into an infinite loop.
>
> (In CL the behavior of a handler is slightly different.  If it
> returns, the exception is re-raised automatically. so in order to
> unwind the stack one must use one of CL's three upward continuations: 
> block/return, tagbody/go, or catch/throw.  The last is dynamically
> scoped, so it is usually the thing to do in this context. 
> Handler-bind, like guard, is a convenience macro for emulating
> stack-unwonding systems._
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan      
>  cowan@ccil.org <mailto:cowan@ccil.org>
> He that would foil me must use such weapons as I do, for I have not
> fed my readers with straw, neither will I be confuted with stubble.
>                         --Thomas Vaughan (1650)
>
Thank you for the examples! They explain, why one would want to have the
flexibility to decide whether to unwind or not to unwind.

I'll try to perhaps add a phrase like "There are some scenarios, in
which not unwinding makes sense, for example …".

I'm glad, that my understanding was not completely wrong.

Regards,
Zelphir