Handling exceptions (lisp errors, NSExceptions ...) in the event thread

[gb]

There are probably several problems with the mechanism(s) used to handle/report exceptions that occur on the Cocoa event thread.

(It is likely that we'd eventually want higher-level debugging facilities - a window based backtrace dialog, interaction with the inspector and other IDE facilities, etc. - to be available when an error occurs during event processing; that's a separate set of issues, and it's likely that anything that we eventually do to address them depend on the issues described here.)

It is necessary that exceptions on the event thread:

• do not block the event process. I've seen log output that shows that the event thread tries to enter a break loop. When the IDE is run standalone, it fills the log file prompting for input from /dev/null.

• unwind the stack in a way that gives both lisp exception handling and unwind-protect cleanup code and any ObjC runtime handlers/cleanups a chance to run. The latter means different things in 32-bit ObjC runtimes than in the 64-bit case. In both cases, it means that lisp errors that occur during ObjC callbacks have to be handled by forcing the callback to raise an NSException on return and by treating NSExceptions that occur during lisp functions that call ObjC methods as lisp errors.

• handle any recursive errors (while printing backtrace info or elsewhere) with the same concerns

• provide as much debugging info as practical (this is currently just stack traces written to standard output.)

I think that we've seen evidence of all of these things failing in some circumstances, sometimes in combination.

We may want to split this ticket into several smaller tickets, but I think that it'd be good to isolate "problems related to exception handling" from things like "backtrace in a TTY is hard to read".

[gz]

I don't know enough Cocoa to know if this is feasible, but just given the set of constraints above, and knowing what I as a user would like to see, this is how I would do it:

When an error occurs in the event thread, do the following:

• Save the stack. This might mean actually copying the stack(s) (for some definition of "copy") ala LWM,or it could mean print a backtrace to a string, or it could mean just saving some pointers. If printing the backtrace, this consists of a sequence of print operations - each one should catch any errors and just print "#<error printing object>".

• hand off the saved stack and any useful information (e.g. current time) to some other process to deal with (e.g. put it on a queue)

• DO NOT UNWIND THE STACK. Get right back to event handling, but do so without unwinding the stack (i.e. recursively enter an event handling loop). This is the part I don't know if it's possible with Cocoa... If it's not possible, then, well, never mind, just do whatever is necessary.

• If if its possible to not unwind the stack, then make up some protocol (e.g. a special kind of event) to let an external process tell us to unwind the stack. When we receive this request, that's when we unwind the stack.

. Have a thread whose job it is to handle the error report from the event thread (this doesn't have to be its only job). It gets the saved stack from the queue, and does whatever it wants - print stuff to the console, print it to the listener, put up fabulous animated dialogs, whatever.

[gb]

I really think that it'd be useful to have at least two separate tickets:

1) how does the current code fail to catch event thread errors that it's supposed to catch ?

2) better ways of presenting error info to the user (and changes necessary to support better ways.)

I don't think that we can get to (2) without addressing (1), and (as I said in the original ticket) I want this ticket to be about (1). Or some ticket to be about (1). Maybe we should close this and open two new tickets.

[jaj]

This should be looked into for Cocoa IDE v1, but I changed the priority from major to normal.