• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Logging entry/exit into methods &/|| functions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Logging entry/exit into methods &/|| functions


  • Subject: Re: Logging entry/exit into methods &/|| functions
  • From: Andy Lee <email@hidden>
  • Date: Sun, 31 Aug 2003 14:36:32 -0400

At 4:27 PM +1000 8/31/03, Wade Tregaskis wrote:
I've found it to be immensely helpful to log the entry and exit into methods in one of my classes. It notes parameters and return values, and provides a simple mechanism to log messages related the current method.

To do all this I have written a little class which formats the output in a hierarchal & thread-safe fashion. This works well enough, but it fills my methods with the lots of crud - I have about 50 methods in one particular class, which means about 400 extra lines of junk (if you count the #ifndef NDEBUG's).

I assume this means you have 8 extra lines per method, 4 on entry and 4 on exit? Seems to me there must be some way to use C macros to reduce the verbiage.

I haven't tried anything clever with arguments and return types, but I do have a few simple macros I use to log method activity. For example, these two:


#define LogEnteringMethod() { if (GetVerbosityLevel() >= VERBOSITY_DEBUG) LogDebug(@"%@ -- entering %@", [self class], NSStringFromSelector(_cmd)); }

#define LogExitingMethod() { if (GetVerbosityLevel() >= VERBOSITY_DEBUG) LogDebug(@"%@ -- exiting %@", [self class], NSStringFromSelector(_cmd)); }



So I have methods that look like this:


- (void)doSomethingWith:(int)arg1 and:(NSString *)arg2
{
LogEnteringMethod();

// ... do stuff ...

LogExitingMethod();
}


This only adds 2 lines per method, not counting whitespace. The performance overhead is trivial in the stuff I do, but if I wanted to conditionally omit the log messages, I would wrap an #ifdef around the *definitions* of the macros, not their invocation, such that if debug is turned off the macros evaluate to the empty string:


#ifndef NDEBUG

#define LogEnteringMethod()

#define LogExitingMethod()

#endif


BTW, I use similar logging macros to check for various categories of programming error:


// I stick this in methods that I want to force my subclasses
// to override:
#define LogMissingOverride() { if (GetVerbosityLevel() >= VERBOSITY_ERROR) LogError(@"%@ must override %@", NSStringFromSelector(_cmd), [self class]); }

// I stick this in at points where I return early from a method
// as part of recovering gracefully from an error:
#define LogExitingMethodPrematurely(msgString) { if (GetVerbosityLevel() >= VERBOSITY_ERROR) LogError(@"%@ -- exiting %@ early -- %@", [self class], NSStringFromSelector(_cmd), (msgString)); }

// I stick this in init methods that I do not want to ever call
// because they are not the designated initializer:
#define LogNonDesignatedInitializer() { if (GetVerbosityLevel() >= VERBOSITY_ERROR) LogError(@"%@ -- '%@' is not the designated initializer", [self class], NSStringFromSelector(_cmd)); }


If there are no suitable existing systems, I was thinking about rewriting this as a transparent NSObject subclass, to inherit from in whichever classes I want to 'trace' in this fashion.

Could you put the logging methods into a category instead of a subclass? This way all classes you write would have it available, not just the ones that inherit from the special subclass. (You might want to use the logging in your own subclasses of NSView, for example.)

--Andy
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: Logging entry/exit into methods &/|| functions
      • From: Andy Lee <email@hidden>
  • Prev by Date: Re: Moving to Keyed Archiving
  • Next by Date: Re: Logging entry/exit into methods &/|| functions
  • Previous by thread: Logging entry/exit into methods &/|| functions
  • Next by thread: Re: Logging entry/exit into methods &/|| functions
  • Index(es):
    • Date
    • Thread