Intermediate Debugging with Xcode 4.5

[rwenderlich]

This is the official thread to discuss the following blog post: Intermediate Debugging with Xcode 4.5

[shmidt]

This post is extremely useful.

[KingBabar]

Great post!
But for it to be really useful i will need some kind of log level. like: log, warning, error.
Any ideas on how to use breakpoint with log levels?

Thanks

[cpprulez]

Extremely useful post, full of practical tricks!
My favorite one was the #warning. My code unfortunately is full of TODOs, which I completely forget over time, so this is awesome!
Huge thanks for the wonderful tutorial!

[abujar82]

I am new to IOS development . This post is very useful and did tech some features that I am not aware of. Thank you for your time. Also, I would like to give a big thanks to every one in this site for delivering these great tutorials. The raywenderlich website is my first resource for IOS development and every day i can see that i am getting better in my IOS skills. great job

[everydave]

Great post. I especially like the part about breakpoint logging, but I'm hesitant to change to this method because while my code can be littered with a bunch of NSLogs that I use while developing/debugging I know exactly what they are when looking at code. With the breakpoint method, the only visual clue that there's something going is the little breakpoint carrot on the left bar. I have to click and "edit" the breakpoint to discover that it is, in fact a logging one. This is also the case in the breakpoint navigator. Does anyone know of a way to make these types (or any specific) type of breakpoint visually stand out so I can have a clue that it's a logging breakpoint vs some other type?

Thanks!

[VegetarianZombie]

@schmidt Thank you!

@KingBabar Thanks for reading! Can you explain how your log levels are being implemented?

@cpprulez hahahaha ... I hear that. There's nothing like a good warning to get your attention.

@everydave ... I hear what you are saying and at the end of the day, it's what ultimately benefits your workflow. The awesome thing about breakpoint logging is that you can add them a runtime. Also, it would be trivial to wrap NSLog in a wrapper function, then turn on the logging through a debugger command via. a breakpoint. That way, you get the best of both worlds. Thanks for reading the article

[dkb]

Where is this mystical return value in the debugger? I can't seem to get it to appear. I was expecting to see it just from stepping into and out of a method that returns a value.

I also find using breakpoints for logging not very useful. I instead use CocoaLumberjack. This is much faster then NSLog and better yet you can have it log to a file. So when a user has an issue you can get the log file from them.

[spulver]

Great tutorial - thanks a lot Brian.

Maybe it is worth mentioning that the breakpoints are stored in a separate file in the xcode project bundle in the xcuserdata folder.
This means they are stored on user basis - sometimes this is good but stay cool when you think you have lost all your hard work adding the log breakpoints to your project - maybe you just work under a different user.

[gargoyle]

One problem I'm having with this is we lose where we are. I like to put __func__ in the output of my NSLog() so that I know what file/routine I'm currently in. When I use your trick of doing this via a breakpoint, the routine looks like this: ($__lldb_category) $__lldb_expr:

That's not entirely helpful. Is there a way to get the current function name with your method?