From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.user Subject: Re: Exception handling - symbol for encoding exception type? Date: Tue, 08 Mar 2022 19:18:27 +0100 Message-ID: References: <18366d41-ee52-9122-997e-cd18b04ece3f@posteo.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-rZWEVFzqzIyVGE1BFhz0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22396"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.38.3-1 To: Zelphir Kaltstahl , guile-user Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Tue Mar 08 19:21:59 2022 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 1nReT9-0005Zz-7k for guile-user@m.gmane-mx.org; Tue, 08 Mar 2022 19:21:59 +0100 Original-Received: from localhost ([::1]:39186 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nReT8-0000OM-2G for guile-user@m.gmane-mx.org; Tue, 08 Mar 2022 13:21:58 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37258) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nRePo-0002q9-G5 for guile-user@gnu.org; Tue, 08 Mar 2022 13:18:34 -0500 Original-Received: from [2a02:1800:110:4::f00:1a] (port=59408 helo=albert.telenet-ops.be) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nRePm-0002q9-Ml for guile-user@gnu.org; Tue, 08 Mar 2022 13:18:32 -0500 Original-Received: from ptr-bvsjgyhxw7psv60dyze.18120a2.ip6.access.telenet.be ([IPv6:2a02:1811:8c09:9d00:3c5f:2eff:feb0:ba5a]) by albert.telenet-ops.be with bizsmtp id 3uJT2700F4UW6Th06uJTWg; Tue, 08 Mar 2022 19:18:27 +0100 In-Reply-To: <18366d41-ee52-9122-997e-cd18b04ece3f@posteo.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r22; t=1646763507; bh=ah6IsEmq/I15ewPuDOgxGwqZi/6QzmC82xqG3u3L5fA=; h=Subject:From:To:Date:In-Reply-To:References; b=JivcLFWzQRb5AyTbFeu1dsZpzqhJailY+f1c7nBDZ0Wb60MzIFp3vXwzGnTVA4/wr 6t1eLmsHTygtOv6/Ok/tU9UM1hn1Ls/7VDGTPpu21RxpnjSweq38B9iSEfvndPOmMd uyIvKxJnUgkkgkitp4+3a5osI3DFRoOg9Iqx07Kb3FXModufvRy2B4esgeogyH65SS tqjybc+KimqyvLZ14abj4JIlVjzg/7WveG0qG+BPTVMx49DvS4IsJ3jmggvZ+DJ3dL 2dj5DP55BGE9QyGCEX8NkWzF/Z/TI1V+vmrUsxvQLuK0XkGVzoAklJW+5YUjc70c0K HvAtkOtFjrRzA== X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a02:1800:110:4::f00:1a (failed) Received-SPF: pass client-ip=2a02:1800:110:4::f00:1a; envelope-from=maximedevos@telenet.be; helo=albert.telenet-ops.be X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 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:18165 Archived-At: --=-rZWEVFzqzIyVGE1BFhz0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Zelphir Kaltstahl schreef op di 08-03-2022 om 17:11 [+0000]: > Is the idea, that one should rely merely on the existing > exception types, which are: >=20 > + assertion-failure > + non-continuable > + implementation-restriction > + lexical > + syntax > + undefined-variable >=20 > and that one should not try to create additional types? Or > is the idea to encode more specifics into the &message? There's plenty of problems that don't fit with the pre-existing exception types well, so I don't see a problem with defining new exception types. E.g., in Guix, to indicate that a file 'bin/foo' could not be found, we throw a '&search-error': ;; this syntax might be wrong but you get the idea. (raise (condition (make-search-error "bin/foo") (make-fix-hint "add the package foobar to the inputs of baz) (make-location "at this file, that line, that column"))) (actually there are less components due to $REASONS that aren't relevant here) guix/ui then translates this condition to nice error+hint messages (actually it doesn't due to $REASONS that are again not relevant here): FILE:LINE:COLUMN: error: the file bin/foo could not be found hint: Add the package 'foobar' to the inputs of 'baz' I recommend defining new exceptions types instead of fitting everything into &message, that makes catching exceptions easier. Greetings, Maxime. --=-rZWEVFzqzIyVGE1BFhz0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iI0EABYKADUWIQTB8z7iDFKP233XAR9J4+4iGRcl7gUCYied8xccbWF4aW1lZGV2 b3NAdGVsZW5ldC5iZQAKCRBJ4+4iGRcl7p4rAP0YNmkN/mrbitF3qA66jK25GUtP Ph7Vrz2mCfjOHzigXQD/ci3J5LF68s/q2rtk0Qa8CiyxuY9z6KczpVauTkaJkwc= =t1zw -----END PGP SIGNATURE----- --=-rZWEVFzqzIyVGE1BFhz0--