[jira] Updated: (DERBY-454) Adjust StandardException.newException to not accept chained exceptions, use separate method instead

["David Van Couvering (JIRA)" <de...@db.apache.org>]

     [ http://issues.apache.org/jira/browse/DERBY-454?page=all ]

David Van Couvering updated DERBY-454:
--------------------------------------

    Summary: Adjust StandardException.newException to not accept chained exceptions, use separate method instead  (was: Adjust StandardException to not accept chained exceptions -- causes semantic confusion in method signature)

> Adjust StandardException.newException to not accept chained exceptions, use separate method instead
> ---------------------------------------------------------------------------------------------------
>
>          Key: DERBY-454
>          URL: http://issues.apache.org/jira/browse/DERBY-454
>      Project: Derby
>         Type: Improvement
>   Components: Services
>     Versions: 10.2.0.0
>     Reporter: David Van Couvering

>
> DERBY-336 involved fixing a wide set of exceptions that improperly used various overloads of StandardException.newException().  One of the biggest issues was that newException() accepts an underlying "causing" exception as a parameter, and this exception gets chained into StandardException.  Common examples are IOExceptions and SecurityExceptions.  The stack trace of the underlying exception is then printed out you print out the stack trace for the StandardException, and no context is lost.
> The problem is that all other parameters to newException() are Objects.  This means that you could accidentally pass in the underlying exception to the wrong argument and the compiler doesn't complain.  Since these exceptions are viewed only under error conditions, these mistakes often are not detected until the product is out in the field and the message makes no sense.
> The problem is made worse by the fact that sometimes you actually want the message string of the underlying exception to be a parameter to the message of StandardException.
> My recommendation is to require exception chaining to occur only through a completely separate method called setCause().
> I think in the name of convenience (e.g. only writing one line to throw the exception) we have created semantic muddiness, and it is now forcing us to do unnatural acts to get the compiler to catch improper usage. I
> I would like to suggest opening a JIRA item to fix this so the semantics are clear and the compiler can catch mistakes the way it was intended to do so -- with strong typing.
> Perhaps this could be done as part of the larger task of migrating to J2SE 1.4 chained exceptions... I can envision only allow message string arguments to newException(), and chaining exceptions be allowed only by calling a separate method on the exception class,
> so instead of
> stde = StandardException.newException(msgid, ioe, arg1, arg2, ioe);
> you would have
> stde = StandardException.newException(msgid, arg1, arg2, ioe);
> stde.setCause(ioe);
> It's one more line, but the semantics are much more clear.
> I recognize that this is a lot of work to walk through all the calls to newException, but DERBY-336 currently relies on a bit of a ugly trick to force the compiler to catch incorrect uses of newException, and even then it may not catch all mistakes.  Fixing this will fix the overall maintainability of Derby by avoiding completely unhelpful error messages.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira