aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes How much logging? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "How much logging?" Watch "How much logging?" New topic
Author

How much logging?

Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Just wondering what approach you guys took with logging to determine where you should put logging statements?

Three rules so far that I have:

1) Log entry and exit to every method (Andrew Monkhouse gives an example of using this in his book). Include argument information selectively (see point 3).
2) If an exception is caught, then I log the exception.
3) Log method arguments that have a large amount of data at the level of FINEST and don't include the argument information in the entering\exiting log method calls.

I am going to use (1) with classes in my suncerify.db package. So for example my Data class and my DataManager class (my class that deals with file I/O). I think (1) would be an overkill in other classes.

I am going to use (2) everywhere I catch an exception. Because I think in general it's good practice to log an exception that you catch. But I'm not sure if it's a good idea to log the exception if am I going to rethrow it, what you guys think?

I was thinking about logging some information before I throw an exception. But not sure about this approach. Probably best to just log the exception when catching it. Unless there's some important information not available when the exception is caught, then I should log when throwing? What you guys think on this one?

I read a nice little discussion on this on stackoverflow see here.


SCJP (1.4 | 5.0), OCJP (6.0), OCMJD
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5408
    
  13

It's not a must requirement, so you don't have to do it.

I had logging in my most important classes (Data, business service implementations) for debugging purposes. I did nothing more than just printing the method name together with the parameters when entering and printing when you exited the method with the return value (if any). I decided to leave this logging into my application when submitting (and documented its added value), but turned it completely off.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Yep, I know it's not a must requirement. Just wondering what strategies\guidelines people use when logging.
David Byron
Rancher

Joined: Jan 20, 2009
Posts: 172

For the project, I included no logging (though I used some along the way).

For real work, if I'm feeling particularly energetic, I:
(a) log exceptions with a lot of detail useful for debugging
(b) do not log every single entry and exit into every method
(c) do log entry into the methods that kick off logical phases or discrete operations
(d) log passage through legal but uncommon pathways
(e) log notable validation results


SCJD 6, OCPJP7, Baroque Potion, G+
Sean Keane
Ranch Hand

Joined: Nov 03, 2010
Posts: 581

Cheers David. Useful info.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5408
    
  13

I want to add another one:
f) use logging extensively if you have to communicate with a 3rd party library or application. It will give you valuable information when the performance of your application is questioned.
David Byron
Rancher

Joined: Jan 20, 2009
Posts: 172

Roel De Nijs wrote:I want to add another one:
f) use logging extensively if you have to communicate with a 3rd party library or application. It will give you valuable information when the performance of your application is questioned.

That's a good one.

Premature Optimization: bad
Premature Vindication: smart!
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5408
    
  13

And I forgot this one:
g) if you develop an application which will be used in your company having a lot of offices across the country (world) adding logging (or adding some mechanism you can turn it on/off very easy) will save you a lot of possible headaches. That's one from my personal experience. At one of my former employees I had extensive logging of each executed action together with the amount of time needed to execute it. And when there was a complaint about the sluggishness of the (web) application (run from a small office) I just had to check the logs and noticed the action took the same time as in the headquarter, so the reason had to be something else (e.g. network traffic).
That's also a bit of protection of the reputation of your application: it might get called slow, but you have the figures (statistics) proving the opposite. Never forget: knowledge is power

And my previous point was also from a personal experience. Exactly the same story: our application was called slow and I said it was not our application, but the 3rd party service and they didn't want to investigate the issue at their side. So I decided to add some extra logging around the calls to their service and after the next release of our application I could easily indicate the problem and enforce my first assumption with some statistics. Nobody says bad things about an application I worked on
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How much logging?