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: Re: About exception handling again ... Date: Tue, 4 Aug 2020 01:17:26 +0200 Message-ID: References: <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="23158"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: Guile User To: John Cowan Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Tue Aug 04 01:17:45 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 1k2jiD-0005vV-7s for guile-user@m.gmane-mx.org; Tue, 04 Aug 2020 01:17:45 +0200 Original-Received: from localhost ([::1]:60802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k2jiC-0008PU-AH for guile-user@m.gmane-mx.org; Mon, 03 Aug 2020 19:17:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2ji2-0008P7-K6 for guile-user@gnu.org; Mon, 03 Aug 2020 19:17:34 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:49841) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k2jhz-0006oW-Ki for guile-user@gnu.org; Mon, 03 Aug 2020 19:17:34 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 4BC6A2400FB for ; Tue, 4 Aug 2020 01:17:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1596496648; bh=5yv5xZD7MfdePFLLYiiTPH3GGMpNritj/0b/tb/iM3U=; h=Subject:To:Cc:From:Date:From; b=M0mmcFa+c2v99ycYHdEXLHoWXQFJTw6sD/BM/giMgObUYS5dpDLzYGJ4YGazdKKJ2 hGeHjsfEruziJEc6xA/xy85a1R5kjn4FSbQ+EMgnY6CY6A2GYhm/w8qGeOQy+C+PfC ljQUjL1ayrmO37dchUOqUYHJx2xZNMfNNChPA+IiXRKz1ElpiKnL32bG35A+FlQlHd oiEvRnUUaYK3b/oimNspY41OGQrsktKLx3LNzheHA9a+dYBU2Zh2JathlDuhux9eqw +NZwwmUCr6WCXnEmrphsMSM5F5L1DSpbd2OTXMtrdUak6m5Y6vPzzeNmgMn2ZDlftj JZv4+yTPTbX+Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4BLDLb4LX7z6tmM; Tue, 4 Aug 2020 01:17:27 +0200 (CEST) In-Reply-To: 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/03 19:17:28 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, HTML_MESSAGE=0.001, 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-Content-Filtered-By: Mailman/MimeDel 2.1.23 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:16773 Archived-At: Hello John! On 8/3/20 6:41 AM, John Cowan wrote: > > > On Sun, Aug 2, 2020 at 2:05 PM Zelphir Kaltstahl > > 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 > .  > 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 > 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