[ 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. David > 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
