Re: Improve reporting of I/O, access errors for Emacs

[Eli Zaretskii <eliz@gnu.org>]

> Cc: Emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 12 Sep 2019 13:32:16 -0700
> 
> On 9/12/19 12:34 PM, Eli Zaretskii wrote:
> > We should just set
> > errno and return an error indication, and then let the caller deal
> > with that.
> 
> I don't see how that could work. Callers are typically written in Lisp, 
> and so can't see errno.

There's some kind of misunderstanding here: the 3 functions I
mentioned are not Lisp-callable, they are called, directly or
indirectly, by Lisp primitives written in C.  My point was that in the
code of the primitive itself, we have all the information to decide
whether or not to signal an error; but on lower levels, we don't have
enough context to make such decisions, so we should only return an
error indication from those lower levels.

> For example, suppose Lisp code calls (file-symlink-p "/a/b/c") and Emacs 
> cannot tell whether /a/b/c is a symbolic link because of an I/O error, 
> or because of a timeout in network access, or because /a is a symlink 
> into an unreadable directory, or whatever. If file-symlink-p merely 
> returns nil, there's no way for the Lisp code to know that there was an 
> exceptional situation and the Lisp code will continue based on the 
> incorrect assumption that /a/b/c was not a symlink.

I agree that file-symlink-p, being a primitive, can decide to signal
an error in case of I/O errors.  But I wasn't talking about the level
of primitives, I was talking about lower levels.  E.g.,
file_directory_p has no way of making intelligent decisions regarding
whether its caller should or shouldn't signal an error in some case,
because file_directory_p can be called in a variety of use cases and
contexts, about whose details it knows nothing at all.

> > That's too small a sample, so it doesn't prove much in my book, sorry.
> 
> I've looked at and experimented with a reasonable amount of Elisp code, 
> and haven't run into problems with the proposed patch. What's your 
> contrary intuition based on? Can you give a realistic example of the 
> problems you see from the patch?

See above: it sounds wrong to delegate to very low levels an authority
of failing the entire higher-level application, since those low levels
don't have enough context information to make such decisions.