db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6
Date Wed, 02 Aug 2006 16:28:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425281 ] 
            
Rick Hillegas commented on DERBY-1629:
--------------------------------------

Here are various ways to tackle this problem:

1) We could create a parallel universe of SQLException subclasses, which extend the JDBC4
SQLException subclasses and implement some vacuous, Derby-specific interface. These would
be the exceptions raised by SQLExceptionFactory40. EmbedSQLException could implement this
vacuous interface too. In the code above (StandardException.unexpectedUserException()), we
could then check whether the exception class was an instance of the vacuous interface.

+ I think this covers the cases
- Bloats up the server with around 20 new classes
- As more SQLException subclasses are added to JDBC, we will have to add additional parallel
Derby classes

2) We could check whether the errorCode was one of the Derby-specific severities. This would
be our flag that the exception was generated by Derby.

+ Not a lot of code bloat.
- Has wormholes: What if the user-created exception uses one of our severities as its error
code?

3) We could check whether the passed-in SQLException's getCause() method returns an EmbedSQLException.
This would be true for all exceptions created by SQLExceptionFactory40

+ Also not a lot of code bloat
- Still has the wormhole that the user-created exception could set a Derby exception as its
cause


> StandardException.unexpectedUserException() does not correctly catch internally generated
exceptions as of JDK 1.6
> ------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1629
>                 URL: http://issues.apache.org/jira/browse/DERBY-1629
>             Project: Derby
>          Issue Type: Bug
>            Reporter: David Van Couvering
>             Fix For: 10.2.0.0
>
>
> In non-JDK 1.6 builds, the exceptions Derby throws are all of class EmbedSQLException.
 As of JDK 1.6, that is no longer true.  Instead we throw a "native" SQL Exception.
> That makes the following code incorrect:
> 	public static StandardException unexpectedUserException(Throwable t)
> 	{
> 		/*
> 		** If we have a SQLException that isn't a Util
> 		** (i.e. it didn't come from cloudscape), then we check
> 		** to see if it is a valid user defined exception range 
> 		** (38001-38XXX).  If so, then we convert it into a 
> 		** StandardException without further ado.
> 		*/ 
> 		if ((t instanceof SQLException) &&
> 		    !(t instanceof EmbedSQLException)) 
> 		{
> 			SQLException sqlex  = (SQLException)t;
> 			String state = sqlex.getSQLState();
> 			if ((state != null) && 
> 				(state.length() == 5) &&
> 				state.startsWith("38") &&
> 				!state.equals("38000"))
> 			{
> 				StandardException se = new StandardException(state, sqlex.getMessage());
> 				if (sqlex.getNextException() != null)		
> 				{	
> 					se.setNestedException(sqlex.getNextException());
> 				}
> 				return se;
> 			}
> 		}
> I am not sure how we can detect internally-thrown SQL Exceptions and distinguish them
from user exceptions, but this does need to be looked at.
> Right now procedureInTrigger.sql is failing for JDK 1.6 due to this error.  I may check
in a jdk16-specific version of this file so at least derbyall can pass.

-- 
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