[Openmcl-devel] objc error handling progress

[Gary Byers]

With code currently in 0.14 CVS (unfortunately, this'll probably never
work in 0.13):

Welcome to OpenMCL Version (Alpha: Darwin) 0.14-030513!
? (require "COCOA")
"COCOA"
? (ccl::create-autorelease-pool)
#<A Mac Pointer #x81B2A0>
? (setq *readtable* ccl::*objc-readtable*)
#<READTABLE #x53EE046>
? (ccl::with-ns-exceptions-as-errors [(ccl::@class "NSObject") "bogus"])
2003-05-18 03:10:09.017 dppccl[17460] *** +[NSObject bogus]: selector not recognized

> Error in process listener(1): Objective-C runtime exception:
>                               *** +[NSObject bogus]: selector not recognized
> While executing: CCL::%ERROR
> Type :POP to abort.
Type :? for other options.
1 >

The #_NSLog output (the message with the timestamp) comes from the
+[NSObject doesNotRecognizeSelector:] method.  I don't know if there's
any way of suppressing this; the #_NSLog call happens before an
exception is even raised.

WITH-NS-EXCEPTIONS-AS-ERRORS should conceptually happen on every message
send (every NSException raised during message execution will cause a
lisp error to be signalled.)  WITH-NS-EXCEPTIONS-AS-ERRORS involves
an UNWIND-PROTECT, a CATCH, some stack-consing, and 3 foreign function
calls; it'll be interesting to see if this measurably affects performance.

I haven't tested the code yet, but lisp errors that occur during
execution of callbacks defined with DEFINE-OBJC-METHOD should cause
those callbacks to return to code which raises a corresponding NSException.
There may be silly fencepost-like bugs in that code, but doing it this
way (playing with the foreign return address and return value of the
callback) should keep the runtime system and GC happy.

There's more work to be done, but the ideas discussed here recently
seem to work.  Sending a message involving an unrecognized (e.g.,
misspelled) selector is usually fatal; being able to get a break
loop when playing around in the listener seems like it'll be a big
improvement.

The event-handling thread probably needs to establish a default
error handler and insure that all event handling happens within
it; I'm not sure that much can be done in that case besides
doing something like #_NSLog and resuming the event loop; you
might be able to fix the problem (or close a window with a
buggy drawRect: method on one of its views) and recover from
the situation.

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel