"Nikodemus Siivola" writes:
> On Dec 4, 2007 12:17 AM, Richard M Kreuter <kreuter@...> wrote:
> 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.