[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception handling - symbol for encoding exception type?

From: Maxime Devos
Subject: Re: Exception handling - symbol for encoding exception type?
Date: Tue, 08 Mar 2022 19:18:27 +0100
User-agent: Evolution 3.38.3-1

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.
      (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.


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]