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.
signature.asc
Description: This is a digitally signed message part
