Sylvain Wallez wrote:
>
> Carsten Ziegeler a écrit :
> >
> > a) always log an exception when it's raised but not when it's catched
> > b) always log an exception when it's catched but not when it's raised
> >
> > I'm +1 on b).
> >
> > Opinions?
>
> +1 on a)
>
> Logging a message _and_ throwing an exception allows :
> - have the log go into the logging category of the component that raised
> the exception,
> - the logging context can hold more information than the exception (see
> logkit ContextMap).
>
Hm, these are two interesting points.

> Does b) means exceptions will be logged in each try/catch of the program
> stack ? Did I miss something or is this what you want to avoid ?
>
No, not in every. Only in the catch block where the exception is consumed,
this means where it is not rethrown.

> My rule of thumb about exceptions is "catch exceptions only if you can
> do something meaningful, otherwhise propagate it".
>
+1

> Some additional rules :
> - never, never, never loose the original exception ! At least wrap the
> it in a CascadingRuntimeException
+100
> - never cascade an exception that you throw (e.g. don't wrap a
> ProcessingException inside a ProcessingException),
+100
> - propagate "as is" RuntimeExceptions.
>
> A typical try/catch block could look as follows :
>
> public void doIt() throws ProcessingException
> {
>   try {
>     ...
>     if (badCondition) {
>       String text = "Bad condition when processing xxx";
>       getLogger().warn(text);
>       throw new ProcessingException(text);
>     }
>     ...
>   } catch(ProcessingException pe) {
>     throw pe;
>   } catch(RuntimeException re) {
>     throw re;
>   } catch(Exception e) {
>     String msg = "Caught an exception while yyy";
>     getLogger().warn(msg);
>     throw new ProcessingException(msg, e);
>   }
> }
>
> Developpers here most often point out the top-level exception when only
> the bottom one is really meaningfull. Having to page down several times
> to see it doesn't help in a fast and clear identification of problems ;)
> This is why exception nesting should be limited as far as possible.
>
> Sylvain
> --
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>


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

Reply via email to