Good point, I agree with you.
Btw it's really a coincidence for me that you're asking this question. I'm involved with some conversations about this very topic at a local university in PA where we're having a hard time finding "best practices" or "standards" in this realm (exception handling, etc.). Mike -----Original Message----- From: Larry Young [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 12:09 AM To: Log4J Users List Subject: RE: when to log Exceptions Mike, Yes, I had thought of something quite similar to that approach. But instead of deciding to log by class type, I had planned on having a simple "boolean hasBeenLogged" in the base Exception class and my logging wrapper class would simply check that flag before doing any work, and it would set it after logging the Exception, whether or not the logger was enabled. I had considered this approach because I wanted to be able to throw one of my Exceptions and let the caller deal with it without having to log it first. If I go simply based on the class type, then no method can throw one of my Exceptions without first logging a message as to why it failed since the logger will ignore my Exception class. --- regards --- Larry At 09:07 PM 3/16/04, you wrote: >Interesting question, should result in some good conversation! > >One approach is to create your own exception type and if you catch that, >you'll know somewhere below you logged it (by convention). If you catch a >Java exception, you'll know it hasn't been logged yet. > >I'm interested to see what tricks others use too. > >Mike > >-----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 -------------------------- Larry Young The Dalmatian Group www.dalmatian.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ------------------------------------------------------------------------------- This message and any included attachments are from Siemens Medical Solutions USA, Inc. and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail with a copy to [EMAIL PROTECTED] Thank you --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
