Phil Steitz <[EMAIL PROTECTED]> wrote on 01/24/2005 05:25:09 PM:

<snip/>

> While I agree with everything that you have said about "indiscriminate 
> logging," I think you are missing Richard's point here.  In some 
> environments, this sort of ad hoc change is not allowed or cannot be 
> executed quickly enough to help resolve a production problem.  The 
> relevant information simply needs to be available in the logs.
> 
> I agree with you that entry/exit logging and other forms of "automatic" 
> instrumentation can create more problems than they solve.  The challenge 

> is to get the right info into the logs without, as you put it, 
> "polluting" them with junk that strains the infrastructure and makes it 
> hard to find the relevant info. Sadly, success here depends much less on 

> what the logging framework provides than what the developer is thinking 
> when deciding when and what to log.

Agreed 100%.  Careful and thoughtful logging should be strongly 
encouraged, and placed at a high priority.

However, logging tends to be an afterthought for many developers, 
something that is sprinkled in during debugging of particular problems... 
hence by it's nature it tends to focus on known problems instead of 
"unknown".  Entry/exit logging won't necessarily "fix" this in some cases, 
but it will provide a minimum of information in those areas of the code 
that have less focus on "thoughtful" logging.  Note also that the minimum 
is sufficient in many cases.

Taking a step back, I do have to agree that "automated and indescriminate" 
logging can result in excessive pollution of a log.  So let me say that 
I'm not advocating that *every* method on every class be instrumented with 
entry/exit: public methods are good candidates, while small helper methods 
are less so.

Let's step back and look at the bigger picture in such situations.

The first thing that comes to my mind is logging related to tight inner 
loops of a program.  I'd be the first to rip "indiscriminate" logging out 
of "tight loops" during runtime or code review.  That said, I'd rather 
have it [automatic] than have nothing.  Pick your poison.

Please, before anyone jumps down my throat, I'm not advocating eliminating 
logging from all loops.  The key point is that we're all ahead when the 
community thinks about all aspects of component development.

> 
> Phil

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development

Reply via email to