




 
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.