[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
About exception handling again ...
About exception handling again ...
Sun, 2 Aug 2020 20:05:29 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.8.0
Hello Guile Users!
In order to update the exception handling examples in my examples
I've spend some time thinking about exception handling, what was written
on the mailing list and some things I read in the reference manual. I
think I understand a bit better now, but I still have some question
marks in my head:
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?
2. My rationale for unwinding the stack is written in the comments in
the example code:
;; From the Guile reference manual:
;; "[...] it’s often the case that one would like to handle an exception by
;; unwinding the computation to an earlier state and running the error handler
;; there. After all, unless the raise-exception call is continuable, the
;; exception handler needs to abort the continuation. To support this use
;; case, if with-exception-handler was invoked with #:unwind? #t is true,
;; raise-exception will first unwind the stack by invoking an escape
;; continuation (see call/ec), and then invoke the handler with the
;; continuation of the with-exception-handler call." --
;; Here the exception is non-continuable, so according to the reference
;; manual, we need to call with-exception-handler with #:unwind? being set to
;; #t for normal exception handling. If we do not do this, a (different?)
;; non-continuable exception is raised.
;; Q: Why unwind the stack?
;; If the execution cannot be continued (non-continuable exception) at the
;; point, where the exception is raised, it means, that in that context, there
;; was insufficient information to continue the execution in useful way.
;; Unwinding the stack means discarding stack frames of procedure calls. This
;; happens up to the point, where an exception handler is defined. The result
;; of unwinding the stack is, that we only leave intact the environment, which
;; was available when the exception handler was defined.
;; We have the knowledge at this point, that an exception occurred. That is
;; more than we knew, when we called the procedure, which raised the
;; exception. Furthermore the exception can contain information about the kind
;; of thing that went wrong. This information hand-over facility should be
;; used to give sufficient information to the exception handler, so that the
;; handler can continue execution in a useful way. The exception enables us to
;; store important information from the environment at the point where the
;; exception was raised. Then we have no need to keep the environment of the
;; point, where the exception was raised and can unwind the stack.
Is this all correct?
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
4. Is there a situation, where one would like to raise a continuable
exception / condition, but also unwind the stack?
5. Are the updated examples correct usage of exception handling?
6. Why is it recommended to make use of (make-exception ...) instead of
the rnrs facilities in Guile? Wouldn't using rnrs stuff be more portable
to other Schemes?
7. I noted from the last discussion the following:
In case of "non-continuable" exceptions the handler procedure given to
~with-exception-handler~ should not return. If it returns, then another
"non-continuable" exception will be raised when it tries to return.
What 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"?
8. What would I need to do to the current updated examples, to make good
Guile 2.2.x examples?
- About exception handling again ...,
Zelphir Kaltstahl <=