bug#56503: Poor error message on missing file using substitute*

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Mittwoch, dem 13.07.2022 um 12:23 +0200 schrieb Daniel Meißner:
> Hi,
> 
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> 
> > When substitute* encounters a nonexistent file, the error is
> > reported
> > to the guix CLI like so:
> > 
> > [...]
> > 
> > The main error message, "system-error "mkstemp" "~A" ("No such file
> > or
> > directory") (2)" is malformed and doesn't report the actual file
> > which
> > is missing; one must decipher the backtrace for clues as to which
> > file
> > caused the error.
> > 
> > We should improve it :-).
> 
> I am Guix and Guile newbie but looking at the definition of the
> procedure ‘with-atomic-file-replacement’ I think we have to catch the
> (possible) exception of the call to ‘mkstemp!’ and provide a custom
> error message.
> 
> This is because the exception thrown by ‘mkstemp!’ does not contain
> any
> information about which file was tried.  Try this snippet in a Guile
> REPL:
> 
> --8<---------------cut here---------------start------------->8---
> (with-exception-handler (lambda (x) (write x) (newline))
>   (lambda ()
>     (mkstemp! "/non/existing/path/foo.XXXXXX")))
> --8<---------------cut here---------------end--------------->8---
> 
> It prints:
> 
> --8<---------------cut here---------------start------------->8---
> #<&compound-exception components: (#<&external-error> #<&origin
> origin: "mkstemp"> #<&message message: "~A"> #<&irritants irritants:
> ("Datei oder Verzeichnis nicht gefunden")> #<&exception-with-kind-
> and-args kind: system-error args: ("mkstemp" "~A" ("Datei oder
> Verzeichnis nicht gefunden") (2))>)>
> --8<---------------cut here---------------end--------------->8---
> 
> So maybe this is a bug in Guile? Shouldn’t ‘mkstemp!’ list the path
> in the irritants?
IMHO this matters little, as one can let-bind the filename or (as we do
it) take it as argument.  The reason Guile does not report it is
probably because it's converted from a POSIX errno, which lacks that
context :)

What's a little more confusing is that a throw-handler is installed
directly after mkstemp!, which re-raises the exception.  This is an
alternative way of failing when the file does not exist, as it wraps
call-with-input-file.

Cheers