Xcode/LLDB being needlessly terse

Question

For a while now, I've been having an issue where I'll cause an assertion to fail in some library code somewhere and Xcode is not forthcoming about what I did.
Normally when this happens (for example when you delete tableview rows but don't remove them from the data source), you get an error like this in the log:

*** Assertion failure in -[SomeClass someMethodName:], /Some/Source/Path/File.m:###
*** Terminating app due to uncaught exception 'SomeException', reason: 'A helpfully descriptive reason for the crash'

Lately, I've been getting the first line, but no second line. It's hard for me to debug on a vague sense of I-did-something-wrong-to-SomeClass. From this point, if I hit continue in the debugger, it just hits the same line (that one we all know in main.m) and changes the stop reason from SIGABRT to EXC_BAD_INSTRUCTION (code=EXC_i386_INVOP, subcode=0x0).

What did I change to discourage Xcode from being helpful and how do I turn helpfulness back on?

Update 2014/11/17:

When I crash an app by putting the wrong thing in an auto layout visual format string, I get no printout at all. It should say something about the view not being found some other error with the string, but it just pauses in the debugger with the same behavior as above. I can't remember whether that error is preceded by an assertion, but if it is then neither is getting printed in this case.

Answer 1

Those error messages are not produced by Xcode. The first comes when an exception is raised in a Foundation method, and the second is output by the uncaught exception handler in Foundation. They are both written to stdout, which is why you see them in the Debugger console window. Note you won't see either message in Xcode when you attach to a process - then the output will go to the Console.app log.

I'm not sure why you aren't getting the second line, maybe something is overriding the default uncaught exception handler?

Anyway, the easiest way to figure out what is happening when an exception is being thrown is to turn on the ObjC exception breakpoint. You can do this in Xcode in the Add Breakpoint popup, or in lldb with:

(lldb) break set -E objc

then when you hit this breakpoint do:

(lldb) po $arg1

The first argument is the exception object being thrown, and the po will print the reason field of the exception.