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 <[email protected]> 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 <[email protected]>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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> +1 !! >>>> >>>> >>>> On Mon, Feb 13, 2012 at 11:47 AM, Chris Pratt >>>> <[email protected]>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 >>> [email protected] >>> http://mailman.qos.ch/mailman/listinfo/logback-user >>> >> >> >> _______________________________________________ >> Logback-user mailing list >> [email protected] >> http://mailman.qos.ch/mailman/listinfo/logback-user >> > > > _______________________________________________ > Logback-user mailing list > [email protected] > http://mailman.qos.ch/mailman/listinfo/logback-user >
_______________________________________________ Logback-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/logback-user
