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.