From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Zelphir Kaltstahl Newsgroups: gmane.lisp.guile.user Subject: About exception handling again ... Date: Sun, 2 Aug 2020 20:05:29 +0200 Message-ID: <2a9a0cf9-cd7c-b118-ee01-f36d6a2e8e31@posteo.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11478"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Icedove/68.8.0 To: Guile User Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Aug 02 20:05:50 2020 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2IMo-0002rQ-BY for guile-user@m.gmane-mx.org; Sun, 02 Aug 2020 20:05:50 +0200 Original-Received: from localhost ([::1]:54868 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k2IMn-0005hU-2d for guile-user@m.gmane-mx.org; Sun, 02 Aug 2020 14:05:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2IMd-0005hG-39 for guile-user@gnu.org; Sun, 02 Aug 2020 14:05:39 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:49201) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2IMa-0000bx-7Y for guile-user@gnu.org; Sun, 02 Aug 2020 14:05:38 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 9E9C62400FE for ; Sun, 2 Aug 2020 20:05:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1596391530; bh=KpHfZqi6QmBUdin/ZUm7GF+BSbMcOWS8l4auTvna/mE=; h=To:From:Subject:Date:From; b=YGhH2iYh83r7rLxJ7Evu6J/FtCB2LDhr2cPljHaa953AUDkFfGqaz0nbUaeTkrCNs uMGAMo0LciN4osS7ZOhD5LNyF4hkkJGQNCOIQgEogbBKp0gQPN23BXyGN3hhJIlGIG OhsPcZojo3VVDKXxJ+ZdaB8W4R60IZVvb8xskP+5P/KoPFsFqwkLHazmWmNdMeu6Wz RVVJc9DITM4vYEB7U9YBJyyiFUNBWMPsK0Y4yq3/yhHa53SjtH1HD9npHZDjktu0EK NYgbvv7XRWfFcjQdb1xDegg8OC4RZ2nbwmvccdFTDnlWj1LU/GT5Yc2tzZmXHCL4jU KQUij5QpZedNA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BKTT60fm1z6tmQ for ; Sun, 2 Aug 2020 20:05:29 +0200 (CEST) Content-Language: en-US Received-SPF: pass client-ip=185.67.36.66; envelope-from=zelphirkaltstahl@posteo.de; helo=mout02.posteo.de X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/02 14:05:31 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:16769 Archived-At: 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