[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue: ERROR-NOT-HANDLED (Version 1)

This issue looked pretty non-controversial to me, but I thought I'd
circulate it here for comment before sending it to X3J13.

Any discussion/objections?

References:   Interactive Condition Handling (Condition System, Rev 18, p19)
Edit history: 25-Sep-88, Version 1 by Pitman
Status:	      For Internal Discussion

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.


  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 Case:

  (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.

Current Practice:

  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
  (queinnec@inria.inria.fr). Pitman supports the change.