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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
