Many editor commands and functions signal an error on failure (using
as described below). This causes the current operation to be aborted.
In many cases, the user will not want the operation to abort completely if one of the editor commands it uses is not successful. For example, the operation may involve a search, but some aspects of the operation should continue even if the search is not successful. To achieve this, the user can catch the
using a macro such as
For example, one part of an application might involve moving forward 5 forms. If the current point cannot be moved forward five forms, generally the Editor would signal an error. However, this error can be caught. The following trivial example shows how a new message could be printed in this situation, replacing the system message.
(editor:defcommand "Five Forms" (p)
"Tries to move the current point forward five forms, printing out an appropriate message on failure."
"Tries to move the current point forward five forms."
(editor:message "could not move forward five"))))
editor:editor-error string &rest args
By default this prints a message in the Echo Area, sounds a beep, and exits to the top level of LispWorks, aborting the current operation. The argument
must be a string, which is interpreted as a control string by
. As with editor:message,
can consist of arguments to be processed within the control string.
The behavior is affected by break-on-editor-error.