Re: [Sbcl-devel] Edge cases in ANSI file querying functions

[Richard M K. <kr...@pr...>]

"Nikodemus Siivola" writes:
> On Dec 4, 2007 12:17 AM, Richard M Kreuter <kr...@pr...> wrote:
> 
> --snip-snap--
> 
> I did not read the code, but your summary makes perfect sense to me. The
> only addenda I have to make is that IMO FILE-ERROR's could be more finely
> gradated even if SB-POSIX is not loaded. I'm not saying we need to export &
> document those conditions: SB-IMPL::FILE-MISSING-ERROR is fine.

If people want this, I'm up for it, but I think there are some reasons
not to do so:

(0) First, in my working copy the FILE-ERRORs signalled by the query
    functions contain what strerror(3) returns for the errno.  So a
    vanilla SBCL will offer more precise information than it does now,
    even without introducing any new condition classes in the internals.
    But this is only meant as a convenient user interface detail for
    knowledgeable users, not, not an API.

(1) If we tell users to have their handlers select using condition types
    in SB-POSIX, that would leave the error classes you propose for
    internal use.  But there aren't many calls to ANSI file system
    functions in SBCL itself: I estimate twenty, mostly PROBE-FILE, and
    mostly in COMPILE-FILE and LOAD, which don't need to handle these
    errors in any fancy way (LOAD has to return NIL when
    :IF-DOES-NOT-EXIST is NIL and no loadable file is found, but that's
    trivial).  So in that respect, having fine-grained errors in the
    internals won't buy us much, but would require adding redundant code
    that does the same stuff as code in SB-POSIX.

(2) ISTM that if we want to let the Windows file system code evolve away
    from pretending that Windows is a Unix, it might be good to leave
    internal FILE-ERRORs opaque, and to keep any internal reasoning
    about FILE-ERRORS simple.

So I don't think we need fine grained errors internally, but having them
will cost us some redundant code, and might make certain future
directions more inconvenient.

Regards,
Richard