[转]http://www.russbishop.net/xcode-exception-breakpoints

原文：http://www.russbishop.net/xcode-exception-breakpoints

Many people are not aware of Xcode's powerful features for managing breakpoints during debugging. One such feature is the Exception breakpoint. Go to the Breakpoint navigator pane, click +, then click Add Exception Breakpoint. Cool, now you'll break right at any exception, instead of in main() long after the context has been lost.

However if you happen to use CoreData, you'll discover that it throws and catches exceptions internally as a form of stack unwinding and control flow which makes debugging such an application highly annoying. You can fix that by excluding all CoreData exceptions. First remove the All Exceptions breakpoint, then and add a new Symbolic breakpoint on objc_exception_throw, then set a condition on the Breakpoint for (BOOL)(! (BOOL)[[(NSException *)$eax className] hasPrefix:@"_NSCoreData"]).

That works just fine... on the 32-bit simulator or a 32-bit Mac application. Unfortunately the register names are quite different on 64-bit Intel and both 32-bit and 64-bit ARM:

Architecture	Exception Register
x86	$eax
x86-64	$rdi
ARM	$r0
ARM-64	$x0

We could create an lldb Python script to help us figure out the proper register and setup exception exclusions, but fortunately poster chendo over on StackOverflow has done the work for us.

Just create the script as shown in the answer and hook it up in your ~/.lldbinit. Then you can create the vanilla All Exceptions breakpoint, but make the first action your ignore script with the proper parameters. During execution the breakpoint will be hit, but Xcode will run the command causing it to immediately resume execution. This delay would be intolerable in a tight loop, but exceptions should be exceptional events so the performance should be perfectly acceptable.

This also highlights some awesome power debugging features many people don't take advantage of; if you can script it in Python, you can make Xcode do it for you automatically. Just setup your breakpoint conditions and have Xcode launch one or more scripts in response. You dump network responses, log all initializer parameters for a certain class, and many other things without having to include that code explicitly in every project and gate it behind preprocessor flags.

[1] Who clicks on these kinds of advertisements!? My pet theory is they're designed to weed out those with intelligence and common sense to ensure only the most gullible people become sales leads.