db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-454) Adjust StandardException.newException to not accept chained exceptions, use separate method instead
Date Tue, 12 Jul 2005 01:18:12 GMT
     [ 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


Mime
View raw message