unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>,
	guile-user <guile-user@gnu.org>
Subject: Re: Exception handling - symbol for encoding exception type?
Date: Tue, 08 Mar 2022 19:18:27 +0100	[thread overview]
Message-ID: <d522f3731a1bc7eb37b0f3c1b446299dd976c8a4.camel@telenet.be> (raw)
In-Reply-To: <18366d41-ee52-9122-997e-cd18b04ece3f@posteo.de>

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

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:
> 
> + assertion-failure
> + non-continuable
> + implementation-restriction
> + lexical
> + syntax
> + undefined-variable
> 
> 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.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

  parent reply	other threads:[~2022-03-08 18:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 17:11 Exception handling - symbol for encoding exception type? Zelphir Kaltstahl
2022-03-08 17:48 ` Vivien Kraus
2022-03-08 18:18 ` Maxime Devos [this message]
2022-03-08 18:20 ` Maxime Devos
2022-04-07 21:39   ` Zelphir Kaltstahl
2022-03-08 18:22 ` Maxime Devos
2022-03-08 19:07 ` Olivier Dion via General Guile related discussions

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=d522f3731a1bc7eb37b0f3c1b446299dd976c8a4.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guile-user@gnu.org \
    --cc=zelphirkaltstahl@posteo.de \
    /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).