Jukka Zitting wrote:
On Thu, May 28, 2009 at 6:17 PM, Ceki Gulcu <c...@qos.ch> wrote: No, just that in most cases some essential piece of the puzzle (source code, stack traces, or in this specific example thread names) is not readily available for a variety of different reasons. For example, I've seen lots of log4j configurations without thread names included in the log output. Sure you can ask the configuration to be changed, but that's not very optimal if you're trying to identify a problem that occurs perhaps only once a month in a production environment.
Tautologically, including relevant data in the the log statement, is by construction of my phrase, relevant -- and thus potentially helpful. However, manually including data, such as the date and thread names, which are readily supplied by most the logging frameworks, would be a waste of developer resources. I am just repeating the obvious. It might be that in certain dysfunctional environments, where it is hard to have the admins change logging configuration, it may be easier for the developer to manually add data. However, a dysfunctional environment does not justify the promulgation of a general rule. > In summary, you generally can't trust on having all the potential data > available to support the task of deciphering the meaning of a log > entry, which makes meaningful log messages all the more important. Of course. No one rule fits it all. It all depends on your environment. However, in a "normal" environment, it should be easy to include date and thread name in the logs by configuration. In that case, it would be redundant and wasteful to include the same information by hand (of the programmer). Coming back to the original issue, while in a small number of cases, you might not want to include an accompanying message with an exception, in many other cases, it is desirable to include some contextual message to accompany the exception. In the former case, nothing prevents you from using a constant String for the accompanying message, such as "" or "EXCEPTION OCCURRED". Anyway, this API change is proposed with a certain regularity, every 6 months or so but given that: 1) in many cases it is useful to have a message accompanying an exception (read: The existing API style is actually better.) 2) in other cases, a fixed message String can be used (read: The existing API style allows an easy work around) 3) the style predates to log4j days and is well known (read: The existing SLF4J API style benefits from the status quo effect) there is very small chance (n.b. zero is small) for the suggested change to occur.
BR, Jukka Zitting
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev