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] Created: (DERBY-454) Adjust StandardException to not accept chained exceptions -- causes semantic confusion in method signature
Date Tue, 12 Jul 2005 01:07:10 GMT
Adjust StandardException to not accept chained exceptions -- causes semantic confusion in method

         Key: DERBY-454
         URL: http://issues.apache.org/jira/browse/DERBY-454
     Project: Derby
        Type: Improvement
  Components: Services  
    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);

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:
For more information on JIRA, see:

View raw message