15

Been watching a WWDC video today about new features in xCode 4. They have mentioned that it a good idea to use log message actions on breakpoints along with "automatically continue after evaluation actions" enabled to output a variable's value for instance instead of using NSLogs all the time.

lets say I have something like that:

NSLog(@"URL is : %@", userDocumentsURL);

How would I write a log message action to display userDocumentsURL's value? Is it really a good idea to use the above method instead of NSLog?

PrimeSeventyThree
  • 940
  • 2
  • 9
  • 24

3 Answers3

27

Create a Breakpoint 'Log Message' action. For the log message include something like:

URL is @(char*) [[userDocumentsURL description] UTF8String]@

Alternatively you can create a breakpoint 'Debugger command' action similar to:

po [NSString stringWithFormat:@"URL is: %@", userDocumentsURL]

I prefer using breakpoint actions for logging, as it's arguably easier to clear out a bunch of breakpoints than it is to remove NSLogs. A possible downside to using breakpoints in this fashion is that they are significantly slower (during debugging) than a direct NSLog.

Josh
  • 625
  • 8
  • 15
  • 4
    I wish I knew why a: the debugger is so stupid as to require the char* cast, and b: it doesnt work half the time and c: the apple documentation doesnt make it clear you need the char* and d: why it doesnt complain if the variables dont exist to help you debug. Compare with Eclipse breakpoints for Java which don't even have this feature, so should be much poorer, but allow you to hack it in by putting a print in a condition. This is annoying of eclipse but even so is still much easier since the print requires no special casting and it will stop and tell you about errors – Rhubarb Nov 09 '12 at 09:54
22

Here is a similar solution using NSLog, which might be fewer characters than the other solutions.

debugger command using NSlog

However, unless you add the void like this:

po (void)NSLog(@"the person name is: %@", p.name)

you will get an annoying "nil" printed out with your log. for example:

(lldb) po NSLog(@"foo")
 nil
2013-06-19 14:42:59.025 TheMove[95864:c07] foo

(lldb) po (void)NSLog(@"foo")
2013-06-19 14:43:10.758 TheMove[95864:c07] foo

If you can live with the nil (I can) it's faster to type and easier to remember just the po

Skotch
  • 3,072
  • 2
  • 23
  • 43
-3

I notice that the edit breakpoints feature, while useful and perhaps modern, does not commit to source control, so does not scale to a team of developers. For this reason, I would say that when working on a team under source control to stick with code-based logging such as NSLog.

Barton Friedland
  • 25
  • 4
  • 4
    I believe it does if you select the correct share options in the breakpoint editor. I don't use this feature myself (solo developer), but the WWDC talks indicate that sharing integrates with source control. – mbm29414 Oct 03 '12 at 18:01
  • 12
    In my opinion not to be forced to read all the debug output of other team members is a pro. You don't have to clean the NSLog (or the // before the NSLog) before committing. I worked on a team where 1 in 10 commits was "removed logging", "added more NSLog", "changed NSLog to be more/less verbose" or anything else related to logging. – Matthias Bauch Feb 08 '13 at 12:56
  • Like @MatthiasBauch just commented this might also be useful. And on the other hand, you should know, there are some usecases where you don't want to restart the app but would like to see a log in the debugger, so this would be the only possibility to do this. – Alex Cio Mar 04 '15 at 17:17