Opened 13 years ago
Last modified 12 years ago
#145 assigned defect
Handling exceptions (lisp errors, NSExceptions ...) in the event thread
Reported by: | gb | Owned by: | gb |
---|---|---|---|
Priority: | normal | Milestone: | Cocoa IDE v1 |
Component: | IDE | Version: | |
Keywords: | Cc: |
Description
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".
Change History (3)
comment:1 Changed 13 years ago by gz
comment:2 Changed 13 years ago by gb
- Status changed from new to assigned
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.
comment:3 Changed 12 years ago by jaj
- Milestone set to Cocoa IDE v1
- Priority changed from major to normal
This should be looked into for Cocoa IDE v1, but I changed the priority from major to normal.
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:
. 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.