From: Maxime Devos <maximedevos@telenet.be>
To: 52724@debbugs.gnu.org
Subject: [bug#52724] [PATCH] guix: Prepare the UI for continuable &warning exceptions.
Date: Wed, 22 Dec 2021 16:27:17 +0000 [thread overview]
Message-ID: <0bc8e7da7afcd9a3e627a2c3e0306588ab517f0a.camel@telenet.be> (raw)
In-Reply-To: <20211221224029.2091-1-attila@lendvai.name>
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.
next prev parent reply other threads:[~2021-12-22 16:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-21 22:40 [bug#52724] [PATCH] guix: Prepare the UI for continuable &warning exceptions Attila Lendvai
2021-12-22 16:27 ` Maxime Devos [this message]
2021-12-23 21:16 ` [bug#52724] [PATCH v2] " Attila Lendvai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0bc8e7da7afcd9a3e627a2c3e0306588ab517f0a.camel@telenet.be \
--to=maximedevos@telenet.be \
--cc=52724@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).