What Xcode (4.2) does is displays the entire stack trace of how the SIGABRT was delivered, but not the actual cause of what caused it.
For me to see this, I have to look at the little text in the console that mentions what happened. The debugger, in this case, only provides a stack trace on information that is unrelated to the problem.
Yeah, I've seen better debugger capabilities in 4.3 and 4.4.1, but we're not moving to this (and having to upgrade to ML in the process) until we're done with our current project (Friday, fingers crossed).
So, maybe I pulled a Romney and "expressed my opinion inelegantly".
From what I have seen in Xcode 4, most of the crashes I have are caused (in code or in the storyboard) are by sending a message to the wrong thing or an "improperly wired up thing". What would be the most beneficial for me, would be to catch this before walking down the SIGABRT trail, since Xcode tells me nothing useful at all when it brings up a SIGABRT (There's nothing useful in the stack trace, really). Putting a breakpoint on the failure case of "this thing does not respond to this message and we're gonna SIGABRT when you try to execute this" is the case where it seems like I want Xcode to do a "bring me to the debugger now so I can see where I screwed up".
With that in mind, I'm going to read up on handing NSExceptions.
Cheers.
On Sep 19, 2012, at 6:28 PM, Jens Alfke wrote:
I'm just proposing this as a more informative way to catch what would be sigaborts before they abort and force your app to stop.
Yeah, but why go to the trouble _this particular_ exception instead of the zillions of other programmer errors that can cause exceptions?
(Note that the crash that triggered this discussion is *not* an uncaught exception, it’s a direct crash of a message-send, probably triggered by a dealloced object. So what you’re proposing wouldn’t have helped here.)
If you wrap the call for non release code you can debug it faster rather than spending the time to find out just what sig aborted.
If you hit an exception you can drop right into the debugger at the point where it’s raised, with the entire stack available to view. (Yes, provided you have set the obligatory exception breakpoint.)
If you return an error code as you suggested, you won’t find out about the problem until later after control has returned to the top level. That seems a lot slower to debug.
I suppose you could rig up your check code to stop the program immediately rather than returning an error. And what’s the best way to do that? Raise an exception :)
—Jens