If an exception is thrown when debugging an iPhone app, without your own exception handling code, that exception won’t stop the debugger until the call stack has totally unwound. On that journey through the call stack it gets caught and disguarded in the event loop. That’s a bummer because then the debugger can’t show you where original exception was raised. This problem is easy to fix by adding a symbolic breakpoint for the runtime’s objc_exception_throw function, which is called as soon as the exception occurs. Here’s how:
1) Run the app in the debugger. There’s an exception we can see in the debugger console:
2) Open the debugger from XCode menu Run->Debugger. The stack we can see where the debugger paused is the useless stack where the event loop code caught the exception and then bombed out with its own exception.
3) From XCode menu Run->Manage Breakpoints -> Add symbolic breakpoint we add ‘objc_exception_throw’
4) Now when we debug run again, the debugger stops as soon as the oringinal exception was thrown, we can see exactly where, and we can poke around an inspect variables etc.
This is a great tip Mark, thanks. I hate when I get that situation in the event loop. This is the kind of thing we would have to do with some of the crappier debuggers I’ve worked with when developing for the GBA or PS2. For example in one of them if you let an assert actually execute it would break the debugger in such a way that all the local variables wouldn’t be available in the debugger. So we’d always have to have a breakpoint set on the assert line so we could get a look at the variables heh.
I have been looking all over for this technique. Though it had been listed elsewhere, your article is well documented and beautifully executed.