From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Bengt Richter Newsgroups: gmane.lisp.guile.bugs Subject: bug#41956: [PATCH] ice-9: exceptions: Properly format the error message. Date: Sun, 28 Jun 2020 20:23:13 +0200 Message-ID: <20200628182313.GA2809@LionPure> References: <87eeqad9m9.fsf@gmail.com> <87wo42mgre.fsf@hurd.i-did-not-set--mail-host-address--so-tickle-me> <20200620183334.GA9490@LionPure> <87r1u9m62o.fsf@gmail.com> <87bll7qx5g.fsf@elephly.net> <20200625163341.GA4622@LionPure> <87tuyvlsuf.fsf@gmail.com> Reply-To: Bengt Richter Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="15131"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: 41956@debbugs.gnu.org To: Maxim Cournoyer Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Sun Jun 28 20:29:34 2020 Return-path: Envelope-to: guile-bugs@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 1jpc3Z-0003oj-Dl for guile-bugs@m.gmane-mx.org; Sun, 28 Jun 2020 20:29:33 +0200 Original-Received: from localhost ([::1]:51186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jpc3Y-0006QM-Er for guile-bugs@m.gmane-mx.org; Sun, 28 Jun 2020 14:29:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52198) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jpbyE-0007s0-F6 for bug-guile@gnu.org; Sun, 28 Jun 2020 14:24:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:35357) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jpbyE-0005oW-5m for bug-guile@gnu.org; Sun, 28 Jun 2020 14:24:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jpbyE-0001wI-1N for bug-guile@gnu.org; Sun, 28 Jun 2020 14:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bengt Richter Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 28 Jun 2020 18:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41956 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 41956-submit@debbugs.gnu.org id=B41956.15933686097411 (code B ref 41956); Sun, 28 Jun 2020 18:24:01 +0000 Original-Received: (at 41956) by debbugs.gnu.org; 28 Jun 2020 18:23:29 +0000 Original-Received: from localhost ([127.0.0.1]:46903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpbxh-0001vT-9h for submit@debbugs.gnu.org; Sun, 28 Jun 2020 14:23:29 -0400 Original-Received: from imta-36.everyone.net ([216.200.145.36]:44774 helo=imta-38.everyone.net) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jpbxe-0001vJ-Cz for 41956@debbugs.gnu.org; Sun, 28 Jun 2020 14:23:28 -0400 Original-Received: from pps.filterd (m0004960.ppops.net [127.0.0.1]) by imta-38.everyone.net (8.16.0.27/8.16.0.27) with SMTP id 05SIDeI7012658; Sun, 28 Jun 2020 11:23:25 -0700 X-Eon-Originating-Account: sh3BKjPTNI3k_fPVXj6L2ZGNdW-gRdwa2MPX3j81_zc X-Eon-Dm: m0116952.ppops.net Original-Received: by m0116952.mta.everyone.net (EON-AUTHRELAY2 - 5a81c77a) id m0116952.5ef2521e.7ade2; Sun, 28 Jun 2020 11:23:23 -0700 X-Eon-Sig: AQMHrIJe+OAbHKoyFgIAAAAD,f158a132b3e460b8b1d9c1ff2ea9c0d0 X-Eip: RPkh7lJnw9MxzJ83RDHnjIs9-WeGXhQT65q1RLhl3js Content-Disposition: inline In-Reply-To: <87tuyvlsuf.fsf@gmail.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.687 definitions=2020-06-28_11:2020-06-26, 2020-06-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1034 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006280138 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.io gmane.lisp.guile.bugs:9836 Archived-At: Hi Maxim, Ricardo, On +2020-06-28 00:25:28 -0400, Maxim Cournoyer wrote: > Hello Bengt, > > Bengt Richter writes: > > > [...] > > > What do you think of using (ice-9 match) to make a universal throwage-formatter, > > with the idea of making readable top level code for how exceptions become messages on screen? > > > > I started a hack to explore the (throw 'whatever any ...) space, beginning like > > > > (use-modules (ice-9 match)) > > (define (make-exception-message key rest) > > (begin > > (let*((l (cons key rest))) > > (match l > > (('system-error subr message args data ...) > > ;; e.g. thrown with key 'system-error: ("open-fdes" "~A" ("No such file or directory") (2)) > > (format #f (string-append "match-1: subr ~s threw '~s " message " sterror: ~s") subr key args (strerror (car (car data))))) > > > > (('signal any ...) > > ;; not yet implemented > > (format #f "match-2: any: ~s" any)) > > Are you proposing to refactor (ice-9 exceptions) so that it's simpler to > follow a condition message is formed for a given exception type? > > Maxim Well, there's probably no catching up with Ludo and Andy, judging from NEWS[1], specifically [2], so practically speaking, no. I was just floating the idea :) You may have noticed the "match-1" in e.g. --8<---------------cut here---------------start------------->8--- > > (format #f (string-append "match-1: subr ~s threw '~s " message " sterror: ~s") subr key args (strerror (car (car data))))) --8<---------------cut here---------------end--------------->8--- above. The idea there was to find easily the exact format expression that did the output, (using the tag, to be included per some debug flag or env, but otherwise doing standard error reporting.) A simple sequence of matches makes it easy to include such debug tags and find them in the code. (not always easy without tags, I found :) I guess if match is sequentially implemented like an if-elif*-else chain, it could be too slow without a generic dispatch to different specialized match sequences, like the dispatch being used now in --8<---------------cut here---------------start------------->8--- define (convert-guile-exception key args) (let ((converter (assv-ref guile-exception-converters key))) (make-exception (or (and converter (converter key args)) (default-guile-exception-converter key args)) (make-exception-with-kind-and-args key args)))) --8<---------------cut here---------------end--------------->8--- ┌────────────────────────────────────────────────────────────────────────┐ │ BTW, I wonder if using a hash table and hashv-ref instead off assv-ref │ │ would make any noticeable speed difference for anyone. │ └────────────────────────────────────────────────────────────────────────┘ The commit diffs on match sequences would become a revision history for the fixes that will probably continue to be necessary, yet the simple surface syntax would be understandable by a newbie. Actually, looking at the code, I think I will get away while I can, before I start seeing udev rules in the mix :) IRL, my next hack might be a (false-if-exception-with-report sexpr) that would ouput to (current-error-port) if an exception does occur, besides returning #f like the plain false-if-exception. First a guaranteed (format (current-error-port) "key=<~s> args=~s\n" key args) seen by the handler, then something more verbose and informative. Just as a hacking tool, when I want to paper something over, but also want to know what's happening ;-) Unfortunately, it probably won't help with syntax errors not finding closing quotes or parens and hitting eof ;/ Hope I haven't annoyed anyone. [1] https://git.savannah.gnu.org/gitweb/?p=guile.git;a=blob_plain;f=NEWS;hb=5e1748f75128107e3a0707b66df5adb95d98437e (I guess that's up to date, I git cloned the repo and first read the NEWS there. LOTS going on ;-) [2] Snip of part I wanted to indicate: --8<---------------cut here---------------start------------->8--- ** Reimplementation of exceptions Since Guile's origins 25 years ago, `throw' and `catch' have been the primary exception-handling primitives. However these primitives have two problems. One is that it's hard to handle exceptions in a structured way using `catch'. Few people remember what the corresponding `key' and `args' are that an exception handler would see in response to a call to `error', for example. In practice, this results in more generic catch-all exception handling than one might like. The other problem is that `throw', `catch', and especially `with-throw-handler' are quite unlike what the rest of the Scheme world uses. R6RS and R7RS, for example, have mostly converged on SRFI-34-style `with-exception-handler' and `raise' primitives, and encourage the use of SRFI-35-style structured exception objects to describe the error. Guile's R6RS layer incorporates an adapter between `throw'/`catch' and structured exception handling, but it didn't apply to SRFI-34/SRFI-35, and we would have to duplicate it for R7RS. In light of these considerations, Guile has now changed to make `with-exception-handler' and `raise-exception' its primitives for exception handling and defined a hierarchy of R6RS-style exception types in its core. SRFI-34/35, R6RS, and the exception-handling components of SRFI-18 (threads) have been re-implemented in terms of this core functionality. There is also a a compatibility layer that makes it so that exceptions originating in `throw' can be handled by `with-exception-hander', and vice-versa for `raise-exception' and `catch'. Generally speaking, users will see no difference. The one significant difference is that users of SRFI-34 will see more exceptions flowing through their `with-exception-handler'/`guard' forms, because whereas before they would only see exceptions thrown by SRFI-34, now they will see exceptions thrown by R6RS, R7RS, or indeed `throw'. Guile's situation is transitional. Most exceptions are still signalled via `throw'. These will probably migrate over time to `raise-exception', while preserving compatibility of course. See "Exceptions" in the manual, for full details on the new API. --8<---------------cut here---------------end--------------->8--- -- Regards, Bengt Richter