How much logging?

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 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.

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

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.

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.

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