Cleanup Issue ERROR-NOT-HANDLED
- Status
- withdrawn; made editorial advice
- Category
- CLARIFICATION/CHANGE
- References
- Interactive Condition Handling (Condition System, Rev 18, p19)
Problem Description
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.
Proposal (PERMIT-TERMINATION)
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 Common Lisp.
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.
Test Cases
(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.
Rationale
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.Current Practice
Probably no one does this yet.Cost to Implementors
None. This change is upward compatible with existing implementations.Cost to Users
None.Cost of Non-Adoption
Saved Lisp images might be forced to be gratuitously larger than they need to be in some implementations.Benefits
Addressing this issue will make Lisp more able to compete with other languages which permit small saved images to result from small user programs.Aesthetics
No significant impact.Discussion
This change was requested by Christian Queinnec of France (queinnec@inria.inria.fr). Pitman supports the change.Edit History
- 25-Sep-88, Version 1 by Pitman