qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie" <ritch...@apache.org>
Subject Re: More Bad Exception Handling.
Date Tue, 10 Apr 2007 13:51:28 GMT
I would have suggested a log of

log.debug/trace("Recasting TypeAE to TypeBE");

So the trace can be shown though the log.

On 10/04/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> This error logging doesn't entirely convince me either:
>
> catch (TypeAException e)
> {
>   log.error("Went wrong!", e);
>   throw new TypeBException(e);
> }
>
> I think I would just do:
>
> catch (TypeAException e)
> {
>   throw new TypeBException(e);
> }
>
> The rethrow here is simply to re-cast the original exception as a different
> type. Presumably it will be logged as an error again somewhere higher up.
>
> Rupert
>
> On 09/04/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> >
> > One problem I've often found with exceptions, is the hassle of writing so
> > many constructors. One for just a message, one for message + wrapped
> > exception, one for message + error code, and every permutation thereof. A
> > simple scheme I've used previously to avoid this is simply to allow
> > parameters in exception constructor to be null, if they are not to be set,
> > and just always use a single constructor. For example:
> >
> > /**
> >  * Root of the application exception hierarchy.
> >  */
> > public class MyException extends Exception
> > {
> >   /**
> >    * @param message May be null if not to be set.
> >    * @param code       May be null if not to be set.
> >    * @param cause     May be null if not to be set.
> >    */
> >   public MyException(String message, Integer code, Throwable cause)
> >   {
> >      super(message == null ? "" : message, cause);
> >      this._errorCode = code == null ? 0 : code.intValue();
> >      ...
> >   }
> > }
> >
> >
> > ...
> > throw new MyException("Went wrong.", null, null);
> >
> > Some people might object to the nulls, but it does take the pain out of
> > writing exception classes.
> >
> > Rupert
> >
> > On 09/04/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> > >
> > > Although, I notice that there is a JMSAMQException specifically for the
> > > case where an AMQException is to be rethrown as a JMSException.
> > >
> > > On 09/04/07, Rupert Smith <rupertlssmith@googlemail.com> wrote:
> > > >
> > > > Yes, there's quite a lot of it in there. I'm going to leave some of it
> > > > well alone for the moment, but fix some things that don't really alter
the
> > > > semantics of the code:
> > > >
> > > > Here's one. Don't do this:
> > > >
> > > > catch (SomeException e)
> > > > {
> > > >    throw new MyException("Something went wrong.");
> > > > }
> > > >
> > > > Do this instead:
> > > >
> > > > catch (SomeException e)
> > > > {
> > > >   throw new MyException("Something went wrong.", e);
> > > > }
> > > >
> > > > of for JMSException which doesn't accept wrapped exceptions through
> > > > its constructors, have to do something like:
> > > >
> > > > catch (SomeException e)
> > > > {
> > > >   JMSException jmse = new JMSException("Something went wrong.");
> > > >   jmse.setLinkedException(e);
> > > >   throw jmse;
> > > > }
> > > >
> > > > This isn't majorly wrong, just annoying to lose half the exception
> > > > stack trace, when tracking down bugs from log files.
> > > >
> > > > Rupert
> > > >
> > >
> > >
> >
>


-- 
Martin Ritchie

Mime
View raw message