Ceki, You seem oddly disparaging of a technology that you've created one of the standard packages for :-), so let's explore a couple of your thoughts from a different perspective.
On Mon, 24 Jan 2005 18:06:21 +0100, Ceki G�lc� <[EMAIL PROTECTED]> wrote: > Richard Sitze wrote on 2005-01-21 20:07:49: > > >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. > > In other words, you are advocating the use of logging as a sort of > persistent debugger. Clearly, a debugger can provide a perfectly > detailed view of the system, down to the register level. However, no > one usually cares about that much detail. Not only is that level of > detail distracting, it will noticeably slow down the application and > hog megabytes of disk space. Is indiscriminate logging IBM's secret > justification for ever bigger and faster machines? I'm certainly not a universal example of how developers work, but thinking back over 25 effort of work in this field, I have consistently found logging more helpful (and interactive debugging less than helpful) at understanding the behavior of complex systems. It's great to be able to dive in with a debugger and see "aha, that value is set to 'foo' but it should really have been 'bar'" -- but that tends not to be the kind of mistake that I make. I usually get the overall control flow wrong when I blow it ... and in a complex system (especially multithreaded ones) it becomes difficult and/or tiresome to locate these kinds of problems with debugging. If I can go back and tweak some logging levels, though, problems like this become much easier to locate. This isn't an argument for or against enter() and exit() as entry points in a logging API (I'm not a fan yet, but not an opponent either) -- but your arguments aren't about that either. You're simply arguing against logging at all, which doesn't seem to make sense to me. > > >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. > > Theoretically speaking, there is no denying that as the quantity of > information about the system increases, so does the probability of > finding the cause of a given error. But where do you stop? You stop adding logging messages when you stop running into bugs :-). But you don't leave them enabled all the time, either. Or, at least *I* don't. If someone wants to leave Digester's debugging level set to trace all the time (which will generate quite a lot of output), though, that's not my concern anyway -- that is the conscious choice of the developer that is using it. On the other hand, without those logging statements being available, it is pretty difficult for most people to understand the dynamic behavior of something based on a SAX parser (as Digester is), which is pretty much backwards to the way most people write code. The ability to turn on those log messages on once in a while is tremendously helpful for this purpose. > > >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. > > Let me present this from a different angle. > > Logging is about fixing the next run, not the current one. The current > one failed, rememberer? So, in some sense, you always have the luxury > of hindsight, almost by construction. > > You can rely on log files with tons and tons of noise, or you can look > at less detailed logs but which still provide a view of the big > picture. Armed with the big picture you can try to reproduce the > problem on your side. Once you are able to reproduce the error, you can > fix it. > > >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 ;-). > > Now that you mention it, one the reasons which got me working on log4j > and its filtering mechanisms, was the thousands of lines of garbage > generated by the logs of an IBM product, which will go unnamed > here. You seem approach logging from a different perspective > altogether: > > Dump as much information as you can, worry about sorting through > the mess later. > > Is that a fair description? If you can't turn it off, enter/exit logging would definitely not be to my taste. But a pretty significant number of my debug and trace log statements tend to be simulations of enter/exit anyway, useful for the reasons described earlier. > > > -- > Ceki G�lc� Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
