commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] API - methods for logging entry and exit events
Date Fri, 21 Jan 2005 20:07:49 GMT
Ceki Gülcü <ceki@qos.ch> wrote on 01/21/2005 01:45:46 PM:

> 
> Logging too much can be as bad as the absence of logging.
> 
> Cluttering the log output with entry and exit events will increase the
> amount of noise and negatively impact the usefulness of the
> logs. Consequenly, logging enter and exit events amount to bad practice.
> 
> For a deployed system, which one would assume has undergone some
> testing, no one, and I mean no one, will care about method entry and
> exit. A developer may have use for entry and exit methods during
> development but such statements should be removed well before the
> application is deployed.

Well Ceki, there are many views out there.  I don't only disagree based on 
opinion of best-practice, I disagree from experience with Enterprise 
[large scale 24/7 business] customers, and person experience with 
developing and maintaining applications running in these spaces.

The purpose of logging is to capture enough state of a system, so that 
when you identify *where* the error occurs in the logs, you have 
information that can help you identify the cause of the error. 
Class/method 'boundries' are convenient for many reasons, not least of 
which is that in a well designed [dare I say OO?] modularized software 
component the methods are [typically] relatively short and "functionally 
defined" by their parameters.  Stack traces for exceptions [if you HAVE an 
exception] can identify a method, but don't capture the state of the 
system in the same way that an entry log entry [eeks] would.  Entry/exit 
help you identify the state of the system at the time a fault occurs, and 
in many cases can identify the fault itself.

Likewise, errors can be caused by earlier events....the entry/exit flow 
information can help identify the factors related to such.. again based on 
conveniant boundries in the code.

I do agree that with some serious planning [thought], and effort that 
there may be more helpful bits of information to log in some cases, but if 
experience shows anything it is that these are typically identified from 
hindsight in many components.  We don't always *have* the luxury of 
hindsight.  In these cases, the more information logged the better.

entry/exit logging is a best-practice that is *easily* understood by 
developers, it provides a minimal set of information that can offer a 
significant improvement over speriodic logging within the code.

Now... if you feel that such methods are not appropriate for the 'general' 
case... while I disagree, I won't argue *too* strongly.. but I would point 
out that we have requested these API's under the guise of 'Enterprise 
Logging' services ;-).

> 
> -- 
> Ceki Gülcü
> 
>    The complete log4j manual: http://www.qos.ch/log4j/
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

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


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message