One of the issues I encountered switching to Xcode, coming from Visual Studio, was related to exceptions. When an exception occurs in Visual Studio it breaks and shows the exact line that caused the exception, but by default Xcode has a different behaviour. When an exception occurs, some kind of general message is shown like “_objc_error”, “EXC_BAD_ACCESS” or “___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___” and no real indication is given where it happened. Stepping through your code to find the faulty line is time consuming and plain stupid.
Luckily you can configure Xcode to break on exception and here’s how. Let me first give you a little bit of background, when the compiler compiles your application in debug-mode, it adds extra information (called symbols) to the executable enabling Xcode to map the running statements to lines of code. This adds some overhead and is the reason (or one of the) why you shouldn’t deploy your application in debug-mode, but rather in release-mode (without the symbols).
That being said, let’s get to the interesting part, Xcode supports 2 kinds of breakpoints: (normal) breakpoints which are placed on a certain line and symbolic breakpoints. Chances are that you’ve worked with normal breakpoints hundreds of times, without knowing there was another type.
Symbolic breakpoints are breakpoints based on the method name instead of the line number of a file, the advantage of this is that the exact location of the method does not have to be known. Open the breakpoints window (Run – Show – Breakpoints) and add two symbolic breakpoints called “objc_exception_throw” and “[NSException raise]“. If you choose to make them in the Global group, they are available in all your projects while the Project group applies to the current project.
These two methods are used to throw an exception, the first one being the most recent style and the latter being the “old & traditional” style, for simplicity’s sake. If you run your code and a exception is raised your code will stop, just like it used to do without the extra symbolic breakpoints. But if you open the debugger (Run – Debugger) and browse the callstack, you should be able to locate the faulty line, which is displayed with a black font color, while the others are light gray. Click on it and your source code will be shown with the “exception throwing line” highlighted. While it’s not as fast/easy like Visual Studio which shows the baddie immediately, looking it up in the debugger works too, right?
Important: while I’ve had great success with this, there have been times when the symbolic breakpoints did not work. The debugger would show the raw statements in the callstack when an exception occured, which is the behaviour without the symbolic breakpoints. I have been able to “fix” this by adding a normal breakpoint (I’ve put it in the method where the exception occured, but I think you can put the breakpoint anywhere) and running the code again, afterward the normal breakpoint could be deleted and the symbolic breakpoints would continue to work. I think it might have something to do with the normal breakpoint causing Xcode to load and/or process all the breakpoints or it’s just me doing something wrong. If anyone knows more about this issue, let me know in the comments.
It has finally happened, Be Tv has been approved and can be