[slf4j-dev] Re: TRACE level

[Endre Stølsvik]

On Tue, 5 Jul 2005, Curt Arnold wrote:

| Two quick comments.
| 
| I'm not fond of the term "ignored".  "error", "warn" and "info" are all
| statements about the developer's assessment of the severity of logging
| request, "ignored" is a statement of what the developer things a diagnostician
| would do with the information.  I would think "expected" would be a better
| term since it is a statement that the developer thought the exception would
| likely occur.

Agree. Although I feel that "trace" is better, as that can be used for 
more than just filling empty catchblocks (btw: why are they empty, 
folks?!)

if (log.isTraceEnabled()) log.trace("Expected Exception.", e);

// within loop construct
  boolean include = object[t].isInclude()
  if (log.isTraceEnabled()) log.trace("Loop counter ["+t"], object here: 
                     ["+objects[t]+"], including:["+include+"].");

whatever.

| 
| I haven't closely followed the "marker" proposal, but possibly it would be
| useful to consider the existing logging hierarchy to be analogous a class
| hierarchy and the marker proposal to be an indication of a desire for
| something like the interface construct where classes in radically different
| parts of the hierarchy could be grouped by some other aspect.  If that was
| followed, then you could see something like a logger declaration including
| both a name (establishing its place in the hierarchy) and a set of "interface"
| names that the logger should participate in.

Ceki's suggestion makes it possible that each log-line have a different 
set of "interfaces" as you define it, while your suggestion would require 
the same scenario to define a -set- of loggers with the interfaces. Both 
are pretty ok and rather similar.

I was just thinking, would letting one logger be attached to several 
categories do exactly the same trick? This wouldn't introduce another 
(problematic) axis...

Endre.


(PS: You all probably know this "trick", but anyway, I find it such a good 
practice, and apparently some developers still don't use it: if you have a 
checked Exception that "will never occur", then still don't let the catch 
block be empty. At some point this thing WILL happen, and there is no way 
you'll catch it, or you'll catch something totally weird way down in the 
code.
  Instead, make a "NestedRuntimeException" (they're all nested in java 
1.4, ai - but making it yourself is better as it'll run on 1.0 too then), 
which take a "cause" exception. Then the single-param constructor of that 
exception that takes Throwable automatically sets the message to "This 
Exception/Throwable should never have occurred". At that point you've 
converted the problematic "never occurring" checked Exception into a 
fantastically easy to write Runtime Exception that will carry the actual 
exception that happened - so that _if_ it occurs _anyway_, you'll notice 
and know!)