PROBE-FILE

[Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>]

    Date: Thu, 11 Apr 85 09:07:38 EST
    From: greek@DEC-HUDSON

    ... I agree with Kent that there is no pleasant way of returning all the
    possible errors from PROBE-FILE, and that some kind of objecty signalling
    facility is probably the right way to go.

    However, I just really have a problem with handling "normal" errors
    using an error system.  I can barely keep from gagging when I have to
    wrap an UNWIND-PROTECT around something every six months or so.
    To have to wrap various signal-handling forms all over the place...

Well, in fact one of the "nice" things about this is that because you know
you'll get thrown into the error handler if something funny happens, you
can sometimes write your code without the error handling and add it lazily 
if it's ever needed.

In dialects where PROBEF can fail due to other than file-not-found, you may
have the problem that the program will "finish" but not correctly. At least
if an error is not signalled, you know things worked correctly. For many
applications, this means writing

  (COND ((NOT (PROBEF ...)) ;File is not found
	 ...)
	(T ;File is found
	 ...))

where formerly (with a PROBEF that refuses to err) you might really have
been forced into doing something like:

  (COND ((NOT (PROBEF ...)) ;Hmmm... File is either not found 
			    ;or not available or not correctly named or ...
	 (COND (...hair to figure out what to do if name was bad...)
	       (...hair to figure out what to do if not accessible...
		   machine down? drive offline? file write opened in
	           append mode by someone else and therefore locked?
		   no more of some needed system resource? ...)
	       (T ...the only part i really cared about...)))
	(T ;File is found
	  ...))

in order to be able to get to sleep at night with a clean conscience.

I guess what I'm saying is that in Maclisp, I've always considered programmers
irresponsible if they wrote "simplified" code that didn't handle the hairy
cases because they were just setting up to cause lossage when someone ran 
their program in unusual circumstances.

On the other, Lisp Machine Lisp programmers that don't write code to handle 
the hairy cases are often being sensible. They can have some sense of confidence
that if an unusual situation arises, the program will stop dead in its tracks
instead of producing bad data.

Given the choice between a buggy program that enters the error handler
and a buggy program which just continues to run blindly, I nearly always
prefer the former.

So, perhaps surprisingly, I'm suggesting that using error signalling may
simplify (rather than complicate) the look of code and maybe people with
hairy-construct phobias will actually like this...
-kmp