[
https://issues.apache.org/jira/browse/DERBY-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren updated DERBY-3390:
--------------------------------------
Attachment: DERBY-3390_b.diff
DERBY-3390_a.diff
I'm attaching 2 patches for this.
The first patch I've run suites.All and derbynetclientmats for. the second one
I'll do so shortly...
The two approaches are:
a. don't cast if the SQLException inside the EmbedSQLException is not also an
EmbedSQLException.
b. if the SQLException inside the EmbedSQLException is not also an
EmbedSQLException don't cast, but also check to see if the SQLException has an
SQLState. If so, add (SQLState: #####) to the error message before wrapping in
the 38000 error.
The original test case description throws an SQLException without SQLState, I
modified the test case a little to throw this:
throw new SQLException( "I refuse to return an int!", "5000" );
The output of this with the patches is:
output with patch a:
ij> drop function badFunction;
ERROR 42Y55: 'DROP FUNCTION' cannot be performed on 'BADFUNCTION' because it
does not exist.
ij> create function badFunction()
> returns int
> language java
> parameter style java
> no sql
> external name 'BadFunction.badFunction' ;
0 rows inserted/updated/deleted
ij> values badfunction();
ERROR 38000: The exception 'java.sql.SQLException: I refuse to return an int!'
was thrown while evaluating an expression.
ij> disconnect;
ij> exit;
output with patch b:
ij> drop function badFunction;
ERROR 42Y55: 'DROP FUNCTION' cannot be performed on 'BADFUNCTION' because it
does not exist.
ij> create function badFunction()
> returns int
> language java
> parameter style java
> no sql
> external name 'BadFunction.badFunction' ;
0 rows inserted/updated/deleted
ij> values badfunction();
ERROR 38000: The exception 'java.sql.SQLException: I refuse to return an int!
(SQLState: 5000)' was thrown while evaluating an expression.
ij> disconnect;
ij> exit;
Is the saving of the possible SQLState worth the extra code, or is it even
necessary at all? Or just distracting? If ok, is the approach of adding
(SQLState: ...) ok?
> SQLException thrown from user function kills network connection
> ---------------------------------------------------------------
>
> Key: DERBY-3390
> URL: https://issues.apache.org/jira/browse/DERBY-3390
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1
> Reporter: Rick Hillegas
> Assignee: Myrna van Lunteren
> Attachments: DERBY-3390_a.diff, DERBY-3390_b.diff
>
>
> Thanks to Frank Griffin for pointing out this issue in a derby-dev email
> thread:
> http://www.nabble.com/SQLException-thrown-from-Table-Function-ResultSet-to15241332.html#a15241332
> If a user-coded function throws a SQLException, Derby will try to cast the
> exception to a Derby exception class before shipping the exception to the
> network client. This raises a ClassCastException and kills the connection. I
> have observed this in 10.4, 10.3, 10.2, and 10.1. You can reproduce this
> problem with the following function class and sql script.
> The function class:
> import java.sql.*;
> public class BadFunction
> {
> /**
> * <p>
> * This function just throws a SQLException.
> * </p>
> */
> public static int badFunction()
> throws SQLException
> {
> throw new SQLException( "I refuse to return an int!" );
> }
>
> }
> Here is the SQL script:
> connect 'jdbc:derby://localhost:8246/derby10.4';
> drop function badFunction;
> create function badFunction()
> returns int
> language java
> parameter style java
> no sql
> external name 'BadFunction.badFunction'
> ;
> values ( badFunction() );
> values ( badFunction() );
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
