> 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.
Its an interesting topic with no 100% right answer. My view is:
- Dont log the error at the lowest layer. An error at a lower layer might
be trapped and handled by invoking different valid logic at the higher
layer. I.e. For that caller it may not be an error. It is up to the caller
to determine.
- Since the same can apply to the middle layer (i.e. it acts as a lower
layer, called by methodA), then dont log here either. Catch and take
action, or repackage and rethrow.
- At the higher level the error should be logged
If your exceptions can refer to business logic failures (eg
InvalidAccountException) then you may not want to log them as an error, just
pass them to UI if that is the caller. If you only use exceptions for
"showstoppers" or unexpected conditions (like us), then you should always
log at the top level.
I am assuming that when you log an error some notification to support staff
or an error system will take place. Therefore you dont want to log unless
it really is an error, and preferably only once, but you definitely CANNOT
miss an error.
Therefore an overriding rule is: if you are not positive that the exception
will be dealt with at the higher layer (you may be writing a shared
component called by other code) then log it anyway.
(Also sometimes I play safe by loggin error as a warning at a lower layer
just to guarantee something is in the log, but so any Error event handling
is not triggered until the appropriate layer logs it)
btw I think you should never turn off error logging.
Simon
> -----Original Message-----
> From: Larry Young [SMTP:[EMAIL PROTECTED]
> Sent: Wednesday, 17 March 2004 2: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]
Goldman Sachs JBWere
Disclosure of Interest
ORG: Goldman Sachs JBWere and/or its affiliates expect to receive or intend to seek
compensation for financial and advisory services in the next 3 months from the company
or its affiliates.
GOLDMAN SACHS JBWERE PTY LTD DISCLAIMER
Goldman Sachs JBWere Pty Ltd and its related entities distributing this document and
each of their respective directors, officers and agents ("the Goldman Sachs JBWere
Group") believe that the information contained in this document is correct and that
any estimates, opinions, conclusions or recommendations contained in this document are
reasonably held or made as at the time of compilation. However, no warranty is made
as to the accuracy or reliability of any estimates, opinions, conclusions,
recommendations (which may change without notice) or other information contained in
this document and, to the maximum extent permitted by law, the Goldman Sachs JBWere
Group disclaims all liability and responsibility for any direct or indirect loss or
damage which may be suffered by any recipient through relying on anything contained or
omitted from this document.
Goldman Sachs JBWere does not represent or warrant the attached files are free from
computer viruses or other defects. The attached files are provided, and may only be
used, on the basis that the user assumes all responsibility for any loss, damage or
consequence resulting directly or indirectly from use.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
