Now that I think of it further, I suspect it is not good practice to
hold a test hostage waiting for this bug to be fixed, and I should
probably add a jdk16-specific master file for procedureInTrigger.sql.
I can point the reader of the bug to this master file as a guide to
reproducing the problem...
Any thoughts? Otherwise I'll go ahead and do that...
David
David Van Couvering wrote:
Thanks, Dan, I concur, and thanks for your quick response. I am going
to log it as a bug and not create a jdk16-specific master file for
procedureInTrigger.
I suspect when this bug is fixed a lot of jdk16-specific master files
will be out-of-date. Personally, I am tired of fixing master files, as
the SQLException itch is turning into a bit of a rash :), so you may not
see my jump on fixing this bug...
David
Daniel John Debrunner wrote:
David Van Couvering wrote:
Hi, all. In evaluating diffs currently happening in JDK 1.6 derbyall, I
ran across this strange diff:
398d397
< ERROR 38000: The exception 'java.sql.SQLException: The external
routine is not allowed to execute SQL statements.' was thrown while
evaluating an expression.
Basically what is happening is in JDK 1.6 Derby is not wrapping 38001
inside 38000. The reason? Well, in JDK 1.6, Derby public methods
throws SQLExceptions that are *not* a subclass of EmbedSQLException.
This results in different logic in the method
StandardException.unexpectedUserException():
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;
}
}
So, my question is, should I codify this by creating a jdk16 master file
for procedureInTrigger.sql? Or is this something we need to try and
address?
I think that's a bug. The comment indicates the code is determining if
the error was raised by Derby (nee Cloudscape), if so handle it
according to the SQL standard. The check for EmbedSQLException is no
longer sufficient with the JDBC 4 changes.
Dan.
