6.3.6 Editor errors

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

Function

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 string must be a string, which is interpreted as a control string by format . As with editor:message, args can consist of arguments to be processed within the control string.

The behavior is affected by break-on-editor-error.