[jira] Updated: (DERBY-3390) SQLException thrown from user function kills network connection

["Myrna van Lunteren (JIRA)" <ji...@apache.org>]

     [ 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_c.diff

Attaching patch _c, which manages to get the thrown SQLException back to the client as an SQLException, by basically moving the cast to EmbedSQLException to within the method buildTokenizedSqlerrmc and there, if it's not an EmbedSQLException, do something more along the lines of the method buildPreformattedSqlerrmc.

This however showed some strange behavior in the message: 
1. if the SQLState was shorter than the required 5 characters, or the constructor without SQLState was not used, some characters got nibbled off the front of the message text.
   This was addressed by checking for the separating ':' that's gotten appended to the sqlstate in org.apache.derby.client.am.Sqlca.
2. the SQLExceptions got an additional ':' at the end.
   Turned out this was not new, for instance the derbyall test lang/GetPropertyInfoTest.java shows the same behavior for the missing messages J029 and J030. 
   It appears from the code in org.apache.derby.iapi.services.i18n.MessageService.MessageFormat() that this is done in anticipation of printing the arguments. So, I modified that to only print the ':' when there are arguments.

I think this solution is reasonable. The output of the test case now becomes:
ERROR 38000: The exception 'java.sql.SQLException: I refuse to return an int!' w
as thrown while evaluating an expression.
ERROR null: I refuse to return an int!

(and with SQLException constructor with SQLState of e.g. 5000 (whether that's a good value or not):
ERROR 38000: The exception 'java.sql.SQLException: I refuse to return an int!' w
as thrown while evaluating an expression.
ERROR 5000: I refuse to return an int!)

It's not exactly like Embedded, but closer to it, and does address the ClassCastExceptions.
I plan to commit this soonish.


> 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, DERBY-3390_c.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.