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