[imp-hackers] cl-ext:exit

[Sam Steingold]

On Thu, Jul 2, 2009 at 11:30 AM, Brian Mastenbrook<brian at mastenbrook.net> wrote:
> On Jul 2, 2009, at 9:32 AM, Sam Steingold wrote:
>> (MAPC #'FUNCALL CUSTOM:*FINI-HOOKS*)
> SBCL's interface is very similar:

good.

> I think that, if this interface or one similar to it were to be
> standardized, we might want to change and extend it a little. I think
> there are actually three levels of "recklessness" of exit that should
> be supported. The non-reckless exit mode runs each exit hook in an
> environment where additional restarts are bound to skip to the next
> hook while keeping or switching the current recklessness mode. This
> would change SBCL's current behavior to not unwind when an serious
> condition is issued in an exit hook by default. A partly-reckless mode
> would run the exit hooks with a handler for errors that immediately
> moves on to the next hook. A truly reckless exit would attempt to exit
> with "all due haste", cutting whatever corners are necessary to
> terminate the current session as soon as possible, including skipping
> all hooks and not invoking any unwind-protect cleanup forms.

I think this is an overkill.
the right way is to run the exit hooks like this:

(MAPC (lambda (f) (ignore-errors (muffle-cerrors (funcall #'f))))
    CUSTOM:*FINI-HOOKS*)

(defun muffle-cerror (condition) ; ABI
  (let ((restart (find-noninteractively-invokable-continue-restart condition)))
    (when restart
      (invoke-restart restart))))
(defmacro muffle-cerrors (&body body)
  "(MUFFLE-CERRORS {form}*) executes the forms, but when a continuable
error occurs, the CONTINUE restart is silently invoked."
  `(HANDLER-BIND ((ERROR #'MUFFLE-CERROR))
     , at body))

i.e., to try to continue from continuable errors and ignore all others.

permitting abandoning *exit-hooks* processing because of an error in
one hook is, IMO, wrong, because it breaks modularity.

entering the debugger when the user types (exit) is eminently wrong
and can break non-interactive tools (e.g., cron jobs) in "interesting"
ways.

the only variation is printing a message that a hooks raised a
condition, but that should be controlled by a general verbosity
settings (like the "-verbose" command line option).

-- 
Sam Steingold <http://sds.podval.org>