[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#52724] [PATCH] guix: Prepare the UI for continuable &warning except
From: |
Maxime Devos |
Subject: |
[bug#52724] [PATCH] guix: Prepare the UI for continuable &warning exceptions. |
Date: |
Wed, 22 Dec 2021 16:27:17 +0000 |
User-agent: |
Evolution 3.38.3-1 |
Hi,
>+ (guard* (c ((warning? c)
>+ (if (formatted-message? c)
>+ (apply emit-formatted-warning
>+ (formatted-message-string c)
>+ (formatted-message-arguments c))
>+ (emit-formatted-warning "~a" c))
>+ '())
I think this is better placed right before the 'formatted-message?',
instead of before the 'package-input-error?'. Or maybe inside the
'formatted-message?' clause? If you put it inside the
'formatted-message?' clause, you would get fix hint support for free.
I don't think the empty list as return value is meaningful here,
maybe return nothing at all instead (using (values))?
Also, you can't meaningfully stringify a condition.
E.g.,
(display (condition (make-warning) (make-who-condition 'foo)))
#<&compound-exception components: (#<&warning> #<&origin origin: foo>)>
I don't think "warning: #<& foo:(#<&bar &baz> ...)...>" messages are
very useful, so I would simply not handle warning? conditions that
aren't formatted-message?.
E.g.,:
(guard* (c [...]
((and (warning? c) (formatted-message? c))
do-things)
[...])
[...])
The downside is that, whenever some code raises a &warning that isn't
also a &formatted-message, (guix ui) needs to be adjusted to support it
as well, but that's acceptable I think.
Also, a test or two would be great (unfortunately call-with-error-
handling appears to be untested ...).
Greetings,
Maxime.