I think Yoav said it already when to log: When the exception is caught - be it once or 
a 100 times. Sure that tends to create a lot of log entries but you can always disable 
logging for certain classes/packages and only have those exception log messages 
written/sent out  which occur on the top most level. 
 
If you take the extreme position that all your components (application layers, etc.) 
are totally indepedent (I know, that's only the theory) , I would say it is a must 
that every component logs the exceptions it encounters (i.e. catches) - no matter if 
rethrown or handled by recovery code. 
 
What is also possible (though probably not the most elegant solution) if you are using 
a common base class for all exceptions: Write to a common error log in the exception's 
constructor what the error message and current stack trace is. That way you can be 
sure every exception is logged - but beware of big log files ;-)
 
Regards,
Torben

        -----UrsprÃngliche Nachricht----- 
        Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
        Gesendet: Mi 17.03.2004 14:55 
        An: Log4J Users List 
        Cc: 
        Betreff: Re: RE: when to log Exceptions
        
        

        Yes but when?
        
        Exceptions are often caught and rethrown.
        
        Are you saying log on every catch in which case the log can become clouded 
with lots of repeated info.
        
        Log on first catch makes sense but this isn't always futureproof when code is 
refactored.
        
        I like the idea of an alreadyLogged flag in the exception although I've 
previously considered that exceptions should be immutable.
        
        Bob.
        
        >
        > From: "Shapira, Yoav" <[EMAIL PROTECTED]>
        > Date: 2004/03/17 Wed PM 01:48:18 GMT
        > To: "Log4J Users List" <[EMAIL PROTECTED]>
        > Subject: RE: when to log Exceptions
        >
        >
        > Hi,
        > I'd offer an extremely simple but usually highly effective heuristic:
        > log it when it's caught.  View logging as part of the handling of an
        > exception.
        >
        > Yoav Shapira
        > Millennium Research Informatics
        >
        >
        > >-----Original Message-----
        > >From: Larry Young [mailto:[EMAIL PROTECTED]
        > >Sent: Tuesday, March 16, 2004 10:34 PM
        > >To: [EMAIL PROTECTED]
        > >Subject: when to log Exceptions
        > >
        > >Hello all,
        > >
        > >         This is not exactly a log4j-specific question, but I thought I
        > >would throw it out to this group to get your opinions.
        > >
        > >         I have multiple layers in my web-based application, and each
        > layer
        > >has the possibility of throwing exceptions.  The question I'm
        > struggling
        > >with is when is it best to log these various Exceptions with the
        > intention
        > >of only logging them once.
        > >
        > >         For example, methodA calls methodB which calls methodC and in
        > >there it throws an IOException.  Well methodC can't do anything about
        > it so
        > >it simply allows it to propagate up to methodB, which can't actually do
        > >anything about it either, except that it needs to trap for all
        > Exceptions
        > >so that it can release some private assets, and then rethrows it up to
        > >methodA which really doesn't care about it either so it doesn't handle
        > it,
        > >letting it go up to the caller.
        > >
        > >         Where would you see as being the best place to log this
        > >Exception?  If it gets logged at the lowest layer (methodC), how does
        > the
        > >next layer up (methodB) know not to log it again, since it can't tell
        > which
        > >Exceptions it caused and which were thrown to it.  And the same
        > question
        > >applies to methodA?  If you only log at the highest layer (methodA's
        > >caller), you lose any ability to turn on/off error logging on a
        > >class-by-class basis.
        > >
        > >         Any thoughts on this would be greatly appreciated.  Thanks.
        > >
        > >--- regards ---
        > >Larry
        > >
        > >
        > >--------------------------
        > >Larry Young
        > >The Dalmatian Group
        > >www.dalmatian.com
        > >
        > >
        > >
        > >---------------------------------------------------------------------
        > >To unsubscribe, e-mail: [EMAIL PROTECTED]
        > >For additional commands, e-mail: [EMAIL PROTECTED]
        >
        >
        >
        >
        > This e-mail, including any attachments, is a confidential business 
communication, and may contain information that is confidential, proprietary and/or 
privileged.  This e-mail is intended only for the individual(s) to whom it is 
addressed, and may not be saved, copied, printed, disclosed or used by anyone else.  
If you are not the(an) intended recipient, please immediately delete this e-mail from 
your computer system and notify the sender.  Thank you.
        >
        >
        > ---------------------------------------------------------------------
        > To unsubscribe, e-mail: [EMAIL PROTECTED]
        > For additional commands, e-mail: [EMAIL PROTECTED]
        >
        >
        
        -----------------------------------------
        Email provided by http://www.ntlhome.com/
        
        
        
        ---------------------------------------------------------------------
        To unsubscribe, e-mail: [EMAIL PROTECTED]
        For additional commands, e-mail: [EMAIL PROTECTED]
        
        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to