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] Commented: (DERBY-1629) StandardException.unexpectedUserException() does not correctly catch internally generated exceptions as of JDK 1.6
Date Wed, 02 Aug 2006 17:02:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425296 ] 
David Van Couvering commented on DERBY-1629:

Thanks for your thoughts, Rick.  It seems to me that for (3) if a user set a Derby exception
as a cause, getCause() would return a SQLException, not an EmbeddedSQLException, so I would
argue your wormhole can be closed...

But I don't like how it relies on behavior that could be changed at any time, and it's overloading
the intention of setCause()/getCause().  But unless we go for (1) I can't see any way out
of piggybacking extra semantics on one of the SQLException methods..., and getCause() seems
like the best choice.  

I would suggest that whoever fixes this adds a comment to the SQLExceptionFactory40 code that
indicates that changing the cause will impact other code and describe how and why.


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


View raw message