[Openmcl-devel] error handling differences between 32 and 64 bit versions of CCL 1.7

[Gary Byers]

OBJC:OBJC-MESSAGE-SEND doesn't do anything to catch ObjC exceptions that
occur during its extent.

In the 64-bit ObjC runtime, there's some declarative information attached
to the CCL kernel code that ultimately does foreign funtion calls.  If an
ObjC excteption is raised in the 64-bit runtime, code in that runtime walks
up the stack until it sees a return address that's declared to know how
to handle runtime exceptions; if it finds any such code, it unwinds the stack
and calls that handler.  (There's essentially nothing that has to happen
at runtime unless an exception happens.)

In the 32-bit ObjC runtime exception handlers have to be established
and disestablished.  Actually transferring control to a handler if an
exception occurs is simple (it mostly involves C's setjmp/longjmp mechanism),
but there's a lot of fuss involved in setting things up even if no exception
occurs.


The macro CCL::WITH-NS-EXCEPTIONS-AS-ERRORS is supposed to do the right
things so that a lisp error is signaled if an ObjC exception occurs during
the extent of its body.  Doing:

(ccl::with-ns-exceptions-as-errors (objc:objc-message-send ...))

should invoke your lisp handler in your example (rather than blissfully
longjmping past it.)

The #/ mechanism takes care of this for you.  In many ways, the better
solution to the problem of calling methods that aren't defined in the
interfaces is to use newer interfaces.


On Mon, 15 Aug 2011, Alexander Repenning wrote:

> Tracked down down some tricky differences between the 32 and the 64 bit
> version of CCL 1.7. Error handling appears to be much more fragile in the 32
> bit version, e.g.,
> 
> 
> (in-package :ccl)
> 
> (catch :mouse-info-access-error
> ? ? ? ?(handler-bind
> ? ? ? ? ? ?((condition #'(lambda (Condition)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?(print Condition)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?(throw :mouse-info-access-error :handled))))
> ? ? ? ? ?(objc:objc-message-send (#/sharedApplication ns:ns-application)
> "noSuchMethod")))
> 
> ;; 64 bit version => returns :handled
> ;; 32 bit version => ugly crash
> 
> 
> Is there any way to catch this?
> 
> For the most part this type of error handling is used to access newer parts
> of OS X apis.
> 
> any ideas?
> 
> 
> Alex
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Prof. Alexander Repenning
> 
> 
> University of Colorado
> 
> Computer Science Department
> 
> Boulder, CO 80309-430
> 
> 
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
> 
> 
> 
> 
>