[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ERROR SIGNALLING FUNCTIONS
I believe that use of the error signalling macros in
sections 24.3 and 24.4 of the Common Lisp Reference Manual
(Excelsior edition) will diminish the quality of
applications written in Common Lisp. This note explains my
reasoning. I realize that the note comes quite late, but I
sent in a similar note right after Moon's proposal was
distributed which appears to have been ignored. Please
recognize that my opinions are not necessarily those of
other people working on Common Lisp at Digital.
My basic objection is that the macros incorporate
assumptions about error signalling and error messages that
are inapropriate in most circumstances and hence should not
be promoted by the language. I feel quite strongly about
this issue. Here are my specific objections.
o check-type. In all but the most trivial cases, the
user will have no idea how to enter a new value,
and we wouldn't want the user to know anyway. The
first example in the reference manual, telling the
user that something is not a vector of integers, is
precisely an example of an error message I'd hate
for a user to see. The error message fragment
alleviates this problem somewhat, but again only in
trivial cases.
The other problem with this macro is the use of an
unevaluated string for the error message fragment.
This is quite parochial, and certainly would only
suffice in the country in which the application was
written. At Digital, for example, we like to put
our messages in a file that can be edited by the
user, and invoke a function to obtain the message
when needed.
o assert. This suffers from the same shortcomings as
check-type. In particular, the error message is
actually part of the syntax, and thus couldn't be
evaluated in any case! In addition, the assumption
is made that a rational message could be composed
from one of the generalized-variable references in
order to prompt the user for a new value. I
challenge anyone to do this in a stylish fashion
(note that there were no examples of this in the
manual).
o e(c)typecase. I am quite surprised that Common
Lisp implementors were willing to accept the hair
involved in trying to compose a reasonable message
for this function. Imagine trying to word the
message for types such as a defstruct, a deftype,
or even the relatively simple type (or (mod 16)
(member t nil)). And I hope we'd agree that the
resulting message would only confuse the user, who
would have no idea how to enter a new value.
o e(c)case. Except in the situation where there are
only two or three clauses, I doubt if an
application would want to list all the possible
values from which the user can choose. Even
applications that list all possible commands (e.g.,
Visicalc) do it in their own special style.
o declarations. It is not clear how these macros
interact with declarations. If a function declares
the data item used as the key in one of these
macros, it may be that Common Lisp has already
detected the error and, in many implementations,
signalled it with some other obscure error message.
This completely circumvents the error message
generated by the macro, and renders the macro
useless.
Let us reconsider the inclusion of these macros in Common
Lisp. They address a problem, detection and alteration of
incorrect input by the user, which is better addressed by an
application-specific question asking facility. If we retain
these macros, I suggest that they be used only to signal
uncorrectable internal logic errors.
- Paul C. Anagnostopoulos
-------