One of the hidden gems in Xcode 4.2 is the “Exception Breakpoint” feature. Once you enable it, your debugging life becomes much easier because whenever an exception is thrown in your app, Xcode will bring up the line of code that caused the exception to occur. This is particularly useful if your call stack window is empty (which I have seen happen sometimes while working on iOS apps). Instead of relying on a brief error message in the Output pane, which doesn’t contain much more than the type of exception and its error message, you get to see exactly where the problem is!
You can add an Exception Breakpoint by opening up the Breakpoint Navigator pane, and clicking on the X button in the bottom left corner:
After clicking the “Add Exception Breakpoint…” menu item, you will see this breakpoint configuration view open up:
Click the Done button and you will the new Exception Breakpoint in your list of breakpoints. If you want to have all of your Xcode workspaces include the Exception Breakpoint, right-click (Ctrl + click) on it and open the “Move Breakpoint To” menu item:
After clicking “User” in the submenu, you will see that the Exception Breakpoint is in the User group of breakpoints. Open up another project and it automatically be included in the list of breakpoints.
Happy debugging!
iJoshSmith 
Josh, I tried this and my code still blows up in the “main” entrance place…I am trying to convert an app to IOS 5 using ARC hoping that helps, but my code still blows up and I’m not sure where…Wondering if I am missing something…
This takes me to the line where the exception was thrown but I see no description for the exception.
Yeah, I noticed that. It would be better to have a description. I find that I keep the Exception Breakpoint disabled most of the time, but when I hit a weird error I enable it to see where the problem occurs. At that point, I already usually know what the error description is.
When you hit the breakpoint, use either po $eax or po $r0 in the debug window for simulator and device respectively, this will give you the exception description as it is a pointer to the first argument passed to objc_exception_throw.
Great tip! Yet another undiscoverable, but important, feature of Xcode.
Great post. It is silly that the exception breakpoint isn’t in there by default. It is also silly that it is no longer printing a description of the exception like Xcode 3 used to.
Pingback: Debugging exceptions in Xcode 4.2 | BRAE
Pingback: With Break On Exception enabled app always breaks in main.m in XCODE 4.2 | PHP Developer Resource
Excellent post, have been trying to find the difference between Xcode and AppCode for the last couple of hours and this would appear to be it! (though why it’s not there by default in Xcode puzzles me…) Thank you!
Dear lord! This is awesome. Thank you Josh for publishing this, and also thank you to Chris for that bit about the debugger commands to get a description. One thing I will note is that you can add Actions that can be fired right when that breakpoint goes off, including debugger commands, so I just put $eax and $ro to be fired automatically, so that I get a description no matter if I’m running on device or simulator.
This is definitely a godsend, because I just hit a problem where a wrong selector was being sent to an object that was being passed as part of a notification, so there was no stack trace, and really no way for me to trace it. Thanks guys.