guix-patches
[Top][All Lists]
Advanced

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






reply via email to

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