[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: About exception handling again ...
From: |
Zelphir Kaltstahl |
Subject: |
Re: About exception handling again ... |
Date: |
Tue, 4 Aug 2020 01:17:26 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
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