Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!pacbell.com!att!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: Alan@lcs.mit.EDU (Alan Bawden)
Newsgroups: comp.lang.scheme
Subject: open-input-file [topics from hell, part 2]
Message-ID: <9104221752.AA00289@august>
Date: 22 Apr 91 17:52:00 GMT
References: <9104220310.AA01226@luke.eecs.wsu.edu>
Sender: alan@ai.mit.edu
Organization: The Internet
Lines: 18


   Date: Sun, 21 Apr 91 20:10:47 pdt
   From: Roger Nelson - Grad Student <rnelson@eecs.wsu.edu>
   ...
   What would be wrong with the open file functions simply returing an error
   code rather than a port or #f in the event of an open error.
   ...

As I said before, what's wrong with this is that people will write programs
that forget to check the return value.  I've been there.  This is exactly
the way the early Lisp Machine system handled file open errors, and it was
a total pain.  The problem is that you -always- have to check the return
value before you can start using it as a port, so the return value
overloading gains you nothing.

In the case where you care to handle errors, you are necessarily going to
be engaging in control structure, so passing alternate continuations to the
file opening procedures seems like the perfect solution.