Many editor commands and functions signal an error on failure (using
editor:editor-error
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
editor:editor-error
using a macro such as
handler-case
.
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."
(handler-case
(editor:forward-form-command 5)
(editor:editor-error (condition)
(editor:message "could not move forward five"))))
editor:editor-error
string
&rest
args
Prints a message in the Echo Area, sounds a beep, and exits to the top level of LispWorks, aborting the current operation. The argument
string
must be a string, which may contain formatting characters to be interpreted by
format
. As with
editor:message
,
args
can consist of arguments to be printed within the string.