My tact has always been that trace statement should only be used to
trace entry, and perhaps exit, from a method. Anything within a method
is either debug or info as appropriate, with error and fatal being
self-explanatory.
My reasoning is simply that if I have a particularly thorny issue I'm
trying to work out, I like having a complete trace where the code went,
and especially when its in log format I can print it out and take it to
lunch to trace through if need be. Frequently you only really need the
debug messages though.
Don's comment about leaving "Action was called"-type statements to the
framework is reasonable. I would typically have a trace message as the
first thing in an Action, just because I don't want to absolutely trust
that the Action was actually called, i.e., maybe the log message where
the framework says Action A is being called has three lines between it
and the actual call, in which case it could be misleading. I wouldn't
go nuts if I didn't see such a trace message though. Should it be
considered a "best practice" to have such a message? I could argue that
a user of a framework doesn't necessarily know what logging the
framework itself will put it and therefore they shouldn't assume they
will get what they need. It's a debatable point though.
My other tact is that I put a debug message in before and sometimes
after a statement that I know could fail, or more importantly that might
not itself fail but that could blow something up down the line. Many
times this isn't just "about to do something dangerous"... for instance,
in the call to doGetUser() below, assuming that might fail if session
was null, I might put:
log.debug("Getting user from session " + session):
...before it, and then:
log.debug("user = " + user);
...after it.
In fact, the second one I might put at info level... when an app is in
production, nothing is more annoying than when a problem occurs and you
realize you aren't logging enough to get anywhere in solving it! Of
course your going to try and replicate it in a dev/QA environment with
full logging on, but how many times does a user complain about something
and you can't replicate it? Then, whatever logging the app does at
production level is all you have. Naturally, prudency is important though.
Frank
Ted Husted wrote:
On 12/9/05, Don Brown <[EMAIL PROTECTED]> wrote:
I'd like to see the logging taken down a notch, but perhaps not completely out.
IMO, Mailreader is there to demonstrate Struts best practices and the logging
statements everywhere make one wonder :) Besides, it gives a false impression
Actions need to be long and detailed. I'd rather see if we can get those
Actions down under 10 lines each. Leave "*Action was called"-type statements to
the framework.
As of this week, most of them are, and we're using real Dispatch
actions. Here's the Edit method from RegistrationAction, for example.
public ActionForward Edit(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws Exception {
final String method = Constants.EDIT;
doLogProcess(mapping,method);
HttpSession session = request.getSession();
User user = doGetUser(session);
boolean updating = (user!=null);
if (updating) {
doPopulate(form,user);
}
doSaveToken(request);
return doFindSuccess(mapping);
}
The logging is pushed back into helper methods, but some of the
helpers are more logging than logic:
protected void doSaveToken(HttpServletRequest request) {
if (log.isTraceEnabled()) {
log.trace(Constants.LOG_TOKEN);
}
saveToken(request);
}
I'm thinking we should do things like log the complete stack trace for
exceptions we catch, and such, but retaining all the tracing
statements we now have, just makes it harder to see the trees. I don't
know if I would leave a trace statement for creating a transactional
token in a production application.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
