[logback-user] Compiler selecting wrong Logger method

Tony Trinh tony19 at gmail.com
Mon Feb 13 20:09:51 CET 2012


That seems reasonable to me, but instead of "null" (which could be a
legitimate value), how about an error string that stands out? I suppose the
refactoring inconvenience is minor after all, and the advantages perhaps
outweigh it, especially with your suggested warning print-out.

-Tony

On Mon, Feb 13, 2012 at 1:10 PM, Chris Pratt <thechrispratt at gmail.com>wrote:

> That's a good point, right now it would eat the exception (logging should
> never interfere with the operation of a possibly production system) and
> just log a "null" for that value, which isn't as helpful as it could be.
>  Maybe I could have it log "missing value:0.number" or something like that.
>    (*Chris*)
>
>
> On Mon, Feb 13, 2012 at 9:44 AM, Tony Trinh <tony19 at gmail.com> wrote:
>
>> Actually, I meant the refactoring of a class that was being used by a
>> "new & improved" formatted string. If, for example, I had this formatted
>> string:
>>
>>
>> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
>> {0.enrollmentDate,date,yyyy-MM-dd}",student);
>>
>> and down the road, someone decides to remove the number field from the Student
>> class without realizing it was in use here, the code would compile just
>> fine, but the effect (presumably an exception) would not be noticed until
>> this log statement was executed.
>>
>>
>> On Mon, Feb 13, 2012 at 12:35 PM, Chris Pratt <thechrispratt at gmail.com>wrote:
>>
>>> Well, not exactly.  It works just fine with the Log4j/java.util.logging
>>> style logging, but it would require refactoring any SLF4j {} based
>>> mappings.  Then again, if it was added as an additional option rather than
>>> a replacement, that problem would go away as well.  If you could continue
>>> to get the Logger instances from the LoggerFactory, or a new Log instance
>>> that used my format, you could slowly transition to the "new & improved"
>>> without requiring a wholesale change.
>>>    (*Chris*)
>>>
>>> On Mon, Feb 13, 2012 at 9:24 AM, Tony Trinh <tony19 at gmail.com> wrote:
>>>
>>>> I'm a fan of this idea (if you couldn't already tell). A couple
>>>> disadvantages that come to mind is lack of syntax-checking in the string
>>>> and painful refactoring (it requires the programmer to search every
>>>> formatted string for correctness). In any case, what would be the
>>>> appropriate action for syntax errors that are discovered at runtime?
>>>>
>>>> -Tony
>>>>
>>>> On Mon, Feb 13, 2012 at 12:17 PM, Tony Trinh <tony19 at gmail.com> wrote:
>>>>
>>>>> +1 !!
>>>>>
>>>>>
>>>>> On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt <thechrispratt at gmail.com
>>>>> > wrote:
>>>>>
>>>>>> Sure, it uses an extension of the java.text.MessageFormat syntax that
>>>>>> allows for unlimited formatted varargs, and allows using dot-notation to
>>>>>> prevent evaluation of the methods until it's been deemed necessary.  With
>>>>>> the current libraries (all of them really), you have to evaluate all the
>>>>>> javabeans that hold the data you are looking to log before it's decided
>>>>>> whether to log the information or not.  In other words:
>>>>>>
>>>>>> log.debug("Loading Student [" + sdnt.getNumber() + "] " + sdnt.
>>>>>> getName() + " Enrolled: " + new SimpleDateFormat("yyyy-MM-dd").format
>>>>>> (sdnt.getEnrollmentDate()));
>>>>>>
>>>>>> Means that a lot of work is done and discarded when the debug level
>>>>>> on this file is set to info or less.  SLF4j is a little better, but not
>>>>>> much:
>>>>>>
>>>>>> log.debug("Loading Student [{}] {} Enrolled: {}",new Object[] {sdnt.
>>>>>> getNumber(),sdnt.getName(),new SimpleDateFormat("yyyy-MM-dd").format
>>>>>> (sdnt.getEnrollmentDate())});
>>>>>>
>>>>>> Yes, of course you could (and probably should) wrap each and every
>>>>>> call to the log system in if(log.isDebugEnabled()) {}.  But we all
>>>>>> know that is ugly and easy for Jr programmers to forget.  My library puts
>>>>>> off the evaluation until after it's been decided that the information is
>>>>>> necessary, then efficiently outputs the message, like this:
>>>>>>
>>>>>> log.debug("Loading Student [{0.number}] {0.name} Enrolled:
>>>>>> {0.enrollmentDate,date,yyyy-MM-dd}",student);
>>>>>>
>>>>>> No muss, no fuss and the TextFormat utility is completely usable
>>>>>> standalone (as well as the advanced dot-notation utilities).
>>>>>>    (*Chris*)
>>>>>>
>>>>>>
>>>>
>>>> _______________________________________________
>>>> Logback-user mailing list
>>>> Logback-user at qos.ch
>>>> http://mailman.qos.ch/mailman/listinfo/logback-user
>>>>
>>>
>>>
>>> _______________________________________________
>>> Logback-user mailing list
>>> Logback-user at qos.ch
>>> http://mailman.qos.ch/mailman/listinfo/logback-user
>>>
>>
>>
>> _______________________________________________
>> Logback-user mailing list
>> Logback-user at qos.ch
>> http://mailman.qos.ch/mailman/listinfo/logback-user
>>
>
>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qos.ch/pipermail/logback-user/attachments/20120213/0ebf637c/attachment-0001.html>


More information about the Logback-user mailing list