Menu
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...
633
This also implies that a stack trace is printed top-down. The stack trace first prints the function call that caused the error and then prints the previous underlying calls that led up to the faulty call. Therefore, reading the first line of the stack trace shows you the exact function call that threw an error.
When you run an application in Xcode, the debugger is automatically started and attached to the process of the application. Click the Run button in the top left or press Command + R. From the moment the application is up and running, we can start inspecting the process and, if necessary, debug it.
a call stack is a stack data structure that stores information about the active subroutines of a computer program. A stack trace is a report of the active stack frames at a certain point in time during the execution of a program.
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.
76
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
