bug#51463: Lack of error message in several guix subcommands

[zimoun]

Hi Ludo,

On Sun, 07 Nov 2021 at 23:14, Ludovic Courtès <ludo@gnu.org> wrote:

> I believe commit 4d59596a1c5f6b20870e619cbf67068ac7dd64ff fixes it (the
> issue affected ‘read-error’ exceptions for reasons other than missing
> closing parentheses).

With your fix, I am questioning the ’if’ test.  Introduced before
524c9800afb433cc474132185d8e37f72004adb3.


For instance, it reads,

--8<---------------cut here---------------start------------->8---
/tmp/pkgs/foo.scm:26:1: missing closing parenthesis
--8<---------------cut here---------------end--------------->8---

when Guile reports,

--8<---------------cut here---------------start------------->8---
/tmp/foo.scm:25:1: unexpected end of input while searching for: )
--8<---------------cut here---------------end--------------->8---

and this message is parsed to catch and report the first message,
instead.

Well, I agree that on one hand, Guile error messages seem badly worded
for newcomers.  On the other hand, post
4d59596a1c5f6b20870e619cbf67068ac7dd64ff, the message for extra
parenthesis,

--8<---------------cut here---------------start------------->8---
guix repl: error: read error while loading '/tmp/pkgs/foo.scm': 
/tmp/pkgs/foo.scm:25:23: unexpected ")"
--8<---------------cut here---------------end--------------->8---

is inconsistent from the one for missing parenthesis. Other said, the
then-branch uses ’format’ and the else-branch uses ’report-error’.


Some Guile errors are sometimes cryptic (the reason of “missing closing
parenthesis” I guess), therefore, the question is: do we add ’cond’
branches for each cases? Using “report-error” for all? Or do we only
rely on Guile error messages?  Dropping ’if’ test.


Last, checking and playing with all that, I note that this catch is done
when using ’load*’ and nothing is done for option ’load-path’.


Cheers,
simon