From: Richard M K. <kr...@pr...> - 2007-12-06 23:12:14
|
"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 |