Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!snorkelwacker.mit.edu!ai-lab!zurich.ai.mit.edu!jinx From: jinx@zurich.ai.mit.edu (Guillermo J. Rozas) Newsgroups: comp.lang.scheme Subject: Re: open-input-file [topics from hell, part 2] Message-ID: Date: 24 Apr 91 03:09:05 GMT References: <9104211907.AA25632@august> Sender: news@ai.mit.edu Reply-To: jinx@zurich.ai.mit.edu Organization: M.I.T. Artificial Intelligence Lab. Lines: 47 In-reply-to: carlton@scws1.harvard.edu's message of 23 Apr 91 19:51:55 GMT Horror? Good grief... But I do agree that finer control over such matters is preferable. I don't think that taking care of it with an exception mechanism is the right way to do this - I would much rather write code that looks like (let ((port (open-input-port filename))) (if (not port) (do-something) (proceed-with-one's-business))) rather than (let ((port (begin (install-exception-handler-to-do-something)) (open-input-port filename))) (proceed-with-one's-business)) Matter of taste, I suppose, but I would rather reserve exception handlers for unexpected sorts of circumstances that programs normally would die on, such as functions being applied to arguments of the wrong type or the user hitting the interrupt key, rather than what I think is probably a fairly common circumstance and one which any program that does I/O should be prepared to handle, namely the non-existence of files. The non-existence of an expected file sounds like an unexpected sort of circumstance to me. :-) Clearly both solutions are equipotent. Given control over exceptions, you can (define (my-open-input-port filename) (install-exception-handler-return-false) (open-input-port filename)) although install-exception-handler would probably be a wrapper to limit the extent of the action. The converse is straightforward. The language could choose either mechanism and you could use whichever one you preferred in your code. Personally, I am tired of fixing C programs that do not check the return status of system calls and fail with segmentation violations later on. To avoid having the same thing happen in Scheme, I'd much rather have Scheme's primitives error, and have a reasonable condition system that allows me to handle those errors when needed.