[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: masinter.pa@XEROX.ARPA, common-lisp@SU-AI.ARPA
- Subject: probe-file
- From: Daniel L. Weinreb <DLW@TENEX.SCRC.Symbolics.COM>
- Date: Mon, 15 Apr 85 16:10 EST
- In-reply-to: The message of 11 Apr 85 22:27-EST from masinter.pa@Xerox.ARPA
Date: 11 Apr 85 19:27 PST
I understand your point and disagree. We gave this a great deal of
thought when we were designing our error system.
Note that there is some mutual property of these two functions, in that
either is relatively simple to implement in terms of the other, given an
error system of the imagined complexity of the Common Lisp error system.
Indeed. In Symbolics Common Lisp, probe-file-that-generates-errors is
just probe-file, and probe-file-without-errors can be defined as
(defun probe-file-without-errors (pathname)
(error (values nil error-object))))
Which would you prefer to have in the "standard" Common Lisp? Both?
Which would fit well with "most programs"? Which would "most
programmers" naturally chose if they had both available in their
Given a good error-handler system such as ours, I think the
"generates-errors" is the one that should be provided. In my
experience, doing it the way you suggest (returning error codes) means
that either every function call has to be surrounded by all these forms
to receive the value and test it and so on, or else the programmers get
lazy, leave that stuff out, and when the error conditions happen the
programs plow right along doing all kinds of incorrect things. In our
system, if the programmers have something in particular that they'd like
to do in the face of errors, they can express these things concisely and
clearly, and if they aren't thinking about errors or are just lazy, then
unanticipated errors put the program into an interactive debugger before
they go off and cause more damage.
We've been using this error system for a couple of years and are quite
happy with it.