[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"?


More information about the Openmcl-devel mailing list