[
https://issues.apache.org/jira/browse/VELOCITY-467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627355#action_12627355
]
Nathan Bubna commented on VELOCITY-467:
---------------------------------------
No, i don't think raising the log level for those things is going to be all
that helpful. When those occur due to a mistake, the output should be wrong.
This is error and warning enough, if they can't tell from that what happened,
they can set logging to debug level for more info. This is the general stance
and trend we've decided for Velocity, and i'm loathe to begin making exceptions
in the other direction.
My current log-level guide for Velocity is roughly:
trace - pointless because really, AOP or a debugger is better for this
debug - for anyone looking to find out why their output wasn't as expected
info - useless, don't bother
warn - barely tolerated where some prior setting is preventing a requested
action (really debug ought to be sufficient)
error - hope to soon be just for logging about the exception about to be thrown
you might say that i've come to see log levels as largely pointless, especially
for Velocity. there's only two jobs for logs, tracking down reasons for wrong
behavior (debug) and recording total failures (error). really, when it comes
to logging for component libraries like Velocity, the user (either a framework,
app or different library) is probably a better judge of the "level" of gravity
any log statement should have than the library developer. If in some future
time i rewrite Velocity's logging, you're more likely to see logging
distinguished by category (introspection, macros, parsing, resource management)
and mode (debug, production) than by any sort of level. For now, i'm content
to just mimic the two modes by moving all logging to debug or error levels.
> Throw more exceptions and log less errors
> -----------------------------------------
>
> Key: VELOCITY-467
> URL: https://issues.apache.org/jira/browse/VELOCITY-467
> Project: Velocity
> Issue Type: Improvement
> Components: Engine
> Affects Versions: 1.5 beta1
> Reporter: Will Glass-Husain
> Priority: Minor
> Fix For: 1.6
>
>
> Now that Velocity application exceptions are based on RuntimeException, we
> have more opportunity to use exceptions to signal application level problems.
> I'm particularly concerned about initialization problems that are logged and
> may be missed. We need to review all logged error messages and see if it
> would be more appropriate to throw an exception instead. Some of these
> places we may need to leave as is for backwards compatibility reasons. (e.g.
> macro in the global macro library doesn't parse properly).
> Llewellyn Falco made a good case for this on the dev list recently:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg15067.html
> #####
> I still would like to put in my vote that sending error's to the log is an
> incredibly BAD idea.
> If something is not working, it should be LOUDLY shown as an exception.
> If it is working I don't really need a log.
> The (velocity) log should be there for velocity developers (those programming
> the actual velocity code) not users.
> I don't ever care to see tomcat's log, I care to see the things I log while
> in tomcat.
> Most of all, many many many people do not check the log at all, let alone
> frequently.
> ####
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
