[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
revised BREAK writeup
- To: Common-Lisp at su-ai
- Subject: revised BREAK writeup
- From: MOON at SCRC-TENEX
- Date: Wed, 18 May 1983 17:30:00 -0000
BREAK &optional format-string &rest args
Print the message and go directly into the debugger, without allowing
any possibility of interception by programmed error-handling facilities.
There aren't any error-handling facilities in Common Lisp, but there
might be in particular implementations, and there will be in Common Lisp
in the future. When continued, BREAK returns NIL. It is permissible to
call BREAK with no arguments; it will supply some default message.
BREAK is presumed to be used as a way of inserting temporary debugging
"breakpoints" in a program, not as a way of signalling errors. Thus
continuing from a BREAK would never do anything special, and it does not
take the second FORMAT control-string argument that CERROR takes. This
and the lack of any possibility of interception by programmed
error-handling are the only program-visible differences between BREAK
and CERROR. The interactive debugger may choose to display them
differently, for instance a CERROR's message might be prefixed with
"Error:" and a BREAK's message prefixed with "Break:". This depends on
the user-interface style of the particular implementation. A particular
implementation may choose, according to its own style and needs, to go
into a different debugger when BREAK is called than when an error occurs.
For example, it might go into a plain read-eval-print loop identical to
the top-level one except for the provision of a "continue" command that
causes BREAK to return NIL.
Compatibility note: Maclisp's BREAK takes two optional arguments. The
first would be a string if Maclisp had strings. The second is a boolean
value specifying whether BREAK should break or return immediately. In
Common Lisp one makes a BREAK conditional by putting it inside a conditional
form such as WHEN or UNLESS.