I argued this point recently but was convinced by others that the guard 
can be necessary depending on the environment. Probably a good idea to 
guard by default unless one is sure it is an area that won't impact 
performance.

-Justin

On 3/22/10 9:05 PM, Jody Garnett wrote:
> I usually only use that if I am putting some work into the error
> message; in this case I am just passing the existing message along.
>
> On Tue, Mar 23, 2010 at 10:34 AM, Simone Giannecchini
> <[email protected]>  wrote:
>> I would use guarded logging in front a finer logging statement.
>>
>> Simone.
>> -------------------------------------------------------
>> Ing. Simone Giannecchini
>> GeoSolutions S.A.S.
>> Founder - Software Engineer
>> Via Carignoni 51
>> 55041  Camaiore (LU)
>> Italy
>>
>> phone: +39 0584983027
>> fax:      +39 0584983027
>> mob:    +39 333 8128928
>>
>>
>> http://www.geo-solutions.it
>> http://geo-solutions.blogspot.com/
>> http://www.linkedin.com/in/simonegiannecchini
>> http://twitter.com/simogeo
>>
>> -------------------------------------------------------
>>
>>
>>
>> On Sat, Mar 20, 2010 at 11:46 AM, Jody Garnett<[email protected]>  
>> wrote:
>>> Here is an example of the result:
>>> package org.geotools.data.ows;
>>> import java.util.logging.Level;
>>> import java.util.logging.Logger;
>>> import org.geotools.util.logging.Logging;
>>> public class Foo {
>>>      private static final Logger LOGGER = Logging.getLogger(Foo.class);
>>>
>>>
>>>
>>>      static void example(){
>>>              try {
>>>                  throw new Throwable();
>>>              } catch (Throwable e) {
>>>                  LOGGER.log(Level.FINER, e.getMessage(), e);
>>>              }
>>>      }
>>> }
>>> Jody
>>> On 20/03/2010, at 9:36 PM, Jody Garnett wrote:
>>>
>>> I went to update the code template to have this years date; and tried my
>>> hand at including the boiler plate logger code. I even learned something;
>>> Andrea pointed out that using the class to construct your logger survives
>>> refactoring in ways a package string never would
>>> <codetemplates.xml>
>>>
>>> Feedback? Is this a good idea?
>>>
>>> Jody
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel&#174; Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Geotools-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to