Bill,

I was thinking about file error handling again and I want your
comments.  I'm not sure what to do.

It would be nice if file words didn't have to return an explicit
error code on the stack.  Clearly, words which return a descriptor
or a byte or whatever should return an invalid descriptor or byte
or whatever if they fail, but other words which don't normally
return anything should not have to return an error code which the 
user has to remember to drop.  Examples: FILE!, FPUTC, FSEEK, MAKE,
DELETE.  Is this Right??!!??   Maybe they should return an error
code which the user should have to explicitly deal with?  Is ignoring
an error condition a dubious practice?

Supposing the previous premise (e.g. FPUTC doesn't return an error code
on the stack), then how about using the external variable scheme for
the error code.

Proposed semantics:

Failing operations set the global variable FILE-ERROR to the appropriate
error code.  Zero means no error.  Successful operations do not change the
variable.
  Problems:  User must explicitly clear the variable at some point in
  order to keep from seeing old errors (too painful?).  What about
  operations on multiple files?

Variation:

Maybe there should be a per-file error variable?
  Problems:  Error test routine needs to know which file to test.  Maybe
  this is a good thing anyway, because an error message should be able
  to report which file was involved.  The obvious place to put this variable
  is in the file descriptor structure, but this begins to impose a
  constraint on the implementation; namely the file descriptor returned
  by an open call MUST be the address of a structure (unless an explicit
  function is defined to translate between a file descriptor "magic cookie"
  and the address of the error variable).

Variation:

Every file operation automatically clears the error variable.
  Problems:  Could slow down the file system interface.  Probably not much,
  though, especially if it's carefully implemented.  Also could lose track
  of previous errors.

Totally different scheme:

Errors are exceptions to be handled by an exception-handling mechanism.

  Problem: Not portable to systems without an exception-handling mechanism
  (most systems).  Possibly slow, maybe not (successful operations would
  probably be fast, failing operations don't have to be fast?).


Please comment on these ideas and perhaps propose other ones.  
Please excuse the "restating the obvious" nature of some of the above
analysis; I used this letter to help me clarify my thinking.

Mitch