CODEWITHSUNDEEP
iphonexcode
Philippe Leybaert
Philippe Leybaert

Reputation: 171774

Stack trace or more info on unhandled exception in Xcode/iPhone

Excuse my ignorance, but something's been bugging me about the Xcode debugger when running iPhone applications in the iPhone Simulator.

Sometimes, when I mess something up in Interface Builder, I get an unhandled exception at runtime and I get thrown back to Xcode. The only thing I see is a single line "uncaught exception" or something like that. From what I can see, there's no additional information, let alone a stack trace or anything else that's useful.

I have been developing in Visual Studio for the last decade or so, and I'm used to getting a nice stack trace and complete exception info when something like that happens.

I'm sure I'm simply missing something very obvious... Hopefully...

Upvotes: 51

Views: 19980

Answers (4)

memmons
memmons

Reputation: 40502

The lack of a stack trace is usually indicative of a problem with LLDB (debugger). I love LLDB, but when it comes to showing stack traces and breaking on the exception rather than main in iOS apps, it's a pain in the ass and has been for a few releases now. No idea why Apple hasn't addressed this yet. To fix it is a two-step process:

  1. Edit your current scheme and under the "Run" tab change the debugger from LLDB to GDB.
  2. Go to https://developer.apple.com/bugreporter/ and report the bug so Apple addresses it.

Upvotes: 3

Ben Gotow
Ben Gotow

Reputation: 14894

Hey activa - for more information about runtime exceptions, you should be able to open the debugger console and see more information. I assume you've already done that, but just in case - you can get to it by selecting Run -> Console from the menu. I'm not sure why it doesn't come up automatically!

Upvotes: 2

Brad Larson
Brad Larson

Reputation: 170319

If you add two breakpoints, you should be able to debug these exceptions. To do this, go to Run | Show | Breakpoints and create two global breakpoints (I do them globally because they are so useful in all my applications). The first should be named "objc_exception_throw" and its location should be "libobjc.A.dylib". The second should be "-[NSException raise]" and its location should be "CoreFoundation".

Now, if you start debugging your application with breakpoints enabled, it should break on the throw of these exceptions. You should then be able to see the chain of events that led to the exception within the debugger.

Upvotes: 74

Remus Rusanu
Remus Rusanu

Reputation: 294267

You can wrap your UIApplicationMain in a try/catch:

int main(int argc, char *argv[]) {
    int retVal;
    NSAutoreleasePool * pool;
    @try
    {
    pool = [[NSAutoreleasePool alloc] init];
    retVal = UIApplicationMain(argc, argv, nil, nil);
    }
    @catch(NSException* e)
    {
        NSLog(@"%@", e.reason);
    }
    @finally
    {
    [pool release];
    }
    return retVal;
}

You should also look up into setting an assertion handler while debugging: NSAssertionHandler.

Update: and also the unhandled exception handler: NSSetUncaughtExceptionHandler

Upvotes: 1

Related Questions