Ceki Gülcü <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
