• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

How much logging?

 
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yep, I know it's not a must requirement. Just wondering what strategies\guidelines people use when logging.
 
Rancher
Posts: 175
Clojure Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Sean Keane
Ranch Hand
Posts: 590
Eclipse IDE Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cheers David. Useful info.
 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 175
Clojure Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
reply
    Bookmark Topic Watch Topic
  • New Topic