Newsgroups: comp.lang.scheme Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!bronze!copper!harlan From: harlan@copper.ucs.indiana.edu (Pete Harlan) Subject: Re: open-input-file [topics from hell, part 2] Message-ID: Sender: news@bronze.ucs.indiana.edu (USENET News System) Organization: Indiana University References: <5405@goanna.cs.rmit.oz.au> <9104270655.aa29839@mc.lcs.mit.edu> Date: 27 Apr 91 18:15:28 GMT Lines: 35 cph@altdorf.ai.mit.EDU (Chris Hanson) writes: [...] >Another assumption is that the code that opens the file is a natural >place to detect and handle the error. Again, in my experience, this >isn't the case. Usually, the call to OPEN-{IN,OUT}PUT-FILE is not in >the same place as the handler. When it isn't, returning an error >object requires that all the intermediate code must know about the >possibility for errors, and suitably pass the error object along to >the caller. Often this "passing along" will affect the control >structure of the program, imposing otherwise unnecessary constraints. >This is the second problem: lots of code that isn't interested in the >error must now become aware of it. [...] But that's what continuations are for, right? You can easily write your own 'open-{in,out}put' routine that escapes to your own dynamically-maintained exception handler. That's the way I typically do it in C, using setjmp and longjmp. Returning an error is conceptually simpler, I think. I'd personally like to see the routine take a success and failure continuation, but the world seems to not want primitive Scheme procedures to take continuations. In any case, it is easy enough to roll your own nonlocal exiting mechanism on file failures if you want. You could equally easy to implement the error-returning system on top of the system-enforced nonlocal exit system, if that system gave the handler the continuation to get back to the point of the file call, but the error-returning system is simpler. I dunno. Pete Harlan harlan@copper.ucs.indiana.edu