[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
package system error handling
- To: common-lisp@SU-AI.ARPA
- Subject: package system error handling
- From: David A. Moon <Moon@SCRC-STONY-BROOK.ARPA>
- Date: Fri, 14 Feb 86 14:22 EST
- In-reply-to: <12183342206.27.LOOSEMORE@UTAH-20.ARPA>
Date: Fri 14 Feb 86 11:17:34-MST
From: SANDRA <LOOSEMORE@UTAH-20.ARPA>
I'm trying to figure out what should happen when the reader sees something
like editor:buffer and there isn't a package called "editor" or an external
symbol in it called "buffer". CLtL indicates that the reader should "signal
a correctable error to ask the user what he really wants to do". This is
all pretty vague -- does this mean that if the user continues from the error
some reasonable default action is used (like creating the package or making
the symbol external), or does it mean that the user is presented with a list
of alternative actions and asked to choose one? How is this handled in
other implementations? Does anybody really care?
I think this depends on the user-interaction style and programming-environment
conventions of each particular implementation. It's not primarily a language
In our implementation, the response depends on context. In interactive input,
we explain the problem and permit the user to edit the input to make it correct.
When reading from a non-interactive source, such as a file, we go into the debugger,
allowing suitable recovery choices. For example, reading editor:buffer when only
editor::buffer exists offers to assume a double colon and also offers to call EXPORT.
Other implementations might want to do something different.
In the future, when Common Lisp is extended with error-handling machinery, we
may want to define how these are errors are signalled and allow programmed recovery.