[
http://issues.apache.org/jira/browse/DERBY-1629?page=comments#action_12425354 ]
Daniel John Debrunner commented on DERBY-1629:
----------------------------------------------
I think it's also worth re-validating the requirements, some of the assumptions
about that method are from the old Cloudscape days when any java method could
be executed from SQL. Looking again it seems as though the current behaviour
for routines is wrong and would not require knowing if an exception was thrown
by Derby or not. Other uses of the method might though. The behaviour for
routines is defined in SQL part 13, section 15.1, which seems to boil down to:
If a method throws an exception E then
if (method instance of java.sql.Exception)
{
if SQL state starts with "38", is at least 5 characters and is not 38000
throw an exception with E's SQL state
else
throw an exception with SQL state 39001
}
else
{
throw an exception with SQL state 38000
}
Assuming we can take the meaning of "class of E is java.sql.SQLException" to
mean instanceof and not class has to be java.sql.SQLException,
since this was written before SQLException had sub-classes.
> 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
> Priority: Minor
> 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
