From: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
To: Guile User <guile-user@gnu.org>
Subject: About exception handling again ...
Date: Sun, 2 Aug 2020 20:05:29 +0200 [thread overview]
Message-ID: <2a9a0cf9-cd7c-b118-ee01-f36d6a2e8e31@posteo.de> (raw)
Hello Guile Users!
In order to update the exception handling examples in my examples
repository
(https://notabug.org/ZelphirKaltstahl/guile-examples/src/master/exception-handling),
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." --
;; https://www.gnu.org/software/guile/docs/master/guile.html/Raising-and-Handling-Exceptions.html
;; 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?
;; A:
;; 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
that correct?)
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?
Regards,
Zelphir
--
repositories: https://notabug.org/ZelphirKaltstahl
next reply other threads:[~2020-08-02 18:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-02 18:05 Zelphir Kaltstahl [this message]
2020-08-03 4:41 ` About exception handling again John Cowan
2020-08-03 7:53 ` tomas
2020-08-03 23:17 ` Zelphir Kaltstahl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2a9a0cf9-cd7c-b118-ee01-f36d6a2e8e31@posteo.de \
--to=zelphirkaltstahl@posteo.de \
--cc=guile-user@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).