[ 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
