[Openmcl-devel] control action errors
Alexander Repenning
ralex at cs.colorado.edu
Tue Oct 20 18:57:56 PDT 2009
Handling of errors in CCL 1.4 has improved a lot but there are still
many tricky cases. Say you use any kind of control and set its target
and action that it calls some Lisp method. If some condition gets
raised you have a choice:
1) call the Lisp method directly from Objective-C. An error will be
reported in the altconsole. You get a chance to poke around in the
console, e.g., stack trace in the hope to find the function causing
the issue. Unfortunately, in most cases you cannot really continue.
There is a good chance you get this:
Unhandled exception 10 at 0x9137eaa7, context->regs at #xbfffef1c
Exception occurred while executing foreign code
at __removeHandler2 + 199
? for help
[19527] Clozure CL kernel debugger:
Once you are in the kernel debugger you don't really get back and
sooner or later get the spinning beach ball.
2) wrap up the Lisp call with a error hander, e.g.,
(objc:defmethod (#/activateAction :void) ((self native-target))
;; catch errors to avoid total crash of CCL
(handler-case (invoke-action (lui-control Self))
(error (condition) (format t "~%invoke control action error ~%
control: ~A ~% error: ~A" (lui-control Self) Condition))))
This usually manages to avoid the beach ball scenario but at the same
time does not give you the opportunity to poke around. That is, you
get to know which control cased the problem and what the error was.
Unfortunately, there could be a lot of code that could have raised the
condition in question.
Question: is there any other idea that I am missing to get something
between 1 "lots of info but likely crash" and 2 "no crash but very
limited info"?
Alex
More information about the Openmcl-devel
mailing list