restarts vs debugger command
budden73 at gmail.com
Thu Jul 9 14:51:42 UTC 2015
> You 'access' a debugger stack by using handler-bind and restart-case.
> Then the user uses the debugger that can use the annotations. This
> modular design is a great strength of CL.
Yes, I was wrong. It is easy to capture condition with handler-bind
But what about "normal" operation? E.g. I use "of-system" to declare and assert
that the file is loaded through a correct system. Only a special
variable works there as there is no condition at all.
> You don't understand what I said. I was thinking of a handler-bind
> that does something like
> (handler-bind ((some-asdf-condition (e) ... (restart-case (error e)
> (edit-file () :report ... (funcall *editor* (condition-component
> e)))))) ...)
What edit-file does? It can call external editor, wait while user
finishes the editing
and then retry operation. But in SLIME and Lispworks my code does just
thing: asynchronous message is sent to IDE so that file is opened in
the IDE. The editing
is done in another thread and maybe in anoter process (as with
SLIME/EMACS). Debugger with all restarts is still available, so user
can choose any restart. When user decides what to do, he can invoke
the restart he wants.
After sending a message a control is returned to handler function.
What is the reasonable action of that function? IMO the only
reasonable action is to resignal the condition. This is unnecessary
blinking, or unnecessary output: user just starting to edit, and
resignaling does not supply user with any new useful information.
This is the difference between restart and "debugger command". Restart
either fixes the problem or resignals condition (maybe some new one).
Debugger command (e.g. "show source" or "eval in frame") does another
thing: it just evaluates some code in current context and then returns
to the debugger without restarting.
My extension can be kept separated, but it defines some around method
and thus can interfere with other extensions which could also define
the same method. This is not very good.
Also maybe I can use some wrapper function to asdf::oos instead of
patching asdf, but it will not work in the cases where load-system is
called implicitly, e.g. from ql:quickload.
More information about the asdf-devel