[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: ERROR-NOT-HANDLED (Version 1)
- To: CL-ERROR-HANDLING@SAIL.Stanford.EDU
- Subject: Issue: ERROR-NOT-HANDLED (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 26 Sep 88 18:33 EDT
- Cc: email@example.com
This issue looked pretty non-controversial to me, but I thought I'd
circulate it here for comment before sending it to X3J13.
References: Interactive Condition Handling (Condition System, Rev 18, p19)
Edit history: 25-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
For delivery purposes, some implementations will want to leave out
major sections of runtime support in programs that do not require
them. The debugger is one such section.
However, since ERROR may be called implicitly by a number of Common
Lisp built-in functions, and since the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled, the interactive debugger must be retained in
a saved image of any program that might signal an error unless the
compiler can prove that the error will never go unhandled. This
may be undesirable in some cases and may cause unnecessary bloating
of the saved image.
Permit implementors to designate an implementation-specific mechanism
for asking that unhandled errors cause `termination of the running
program' rather than entry into the system's debugger.
Implementations choosing to offer such a facility must clearly define
the nature and scope of such program termination, since the concept
of `program termination' is an ill-defined concept in present-day
Even when program termination rather than debugger entry would be
the ultimate effect of an unhandled error, the value of
*DEBUGGER-HOOK* (if non-NIL) must be called to provide programmers
the ability of customized debugging.
All implementations must at least provide the option of a system
debugger for use in program development.
(ERROR "Foo"), if unhandled, must now enter the debugger.
Under this proposal, it might also `terminate program execution'
in implementations which choose to provide such a facility and to
clearly define that concept.
Although technically an incompatible change, we're dealing at
the very edge of what the user can expect from the system. Once
an error is signalled and not handled, we're in the domain of
implementation-dependent effect anyway.
Probably no one does this yet.
Cost to Implementors:
None. This change is upward compatible with existing implementations.
Cost to Users:
Cost of Non-Adoption:
Saved Lisp images might be forced to be gratuitously larger than
they need to be in some implementations.
Addressing this issue will make Lisp more able to compete with
other languages which permit small saved images to result from
small user programs.
No significant impact.
This change was requested by Christian Queinnec of France
(firstname.lastname@example.org). Pitman supports the change.