[jira] Commented: (DERBY-3139) setObject and other setXXX methods on PreparedStatement throw different exceptions in Network Server when parameter number is out of range

["Kathey Marsden (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536365 ] 

Kathey Marsden commented on DERBY-3139:
---------------------------------------

I think since this is pretty much a usage error, probably noone is going to have their app check for this particular exception.  We document that network client SQLStates might change in:
http://db.apache.org/derby/docs/10.1/ref/rrefexcept71493.html

so if we change it I think it would be best to keep the embedded state.



> setObject and other setXXX methods on PreparedStatement throw different exceptions in Network Server when parameter number is out of range
> ------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3139
>                 URL: https://issues.apache.org/jira/browse/DERBY-3139
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Server
>    Affects Versions: 10.3.1.4, 10.4.0.0
>            Reporter: Mamta A. Satoor
>
> In Network Server, when a user executes PreparedStatement.setObject with out of range parameter number, the exception thrown is XCL13 but when the user tries PreparedStatement.setString with out of range parameter number, the exception thrown in Network Server is XCL14. We should throw same exception for both the cases. 
> The reason for this difference in behavior is client.am.PreparedStatement.setObject calls checkForValidParameterIndex for parameter number checking and that method throws exception XCL13. 
> All the other PreparedStatement.setXXX methods end up calling getColumnMetaDataX().getColumnType(parameterIndex); which results into call to client.am.ColumnMetaData:getColumnType() which in turn calls checkForValidColumnIndex for parameter number checking and that method throws exception XCL14. 
> I am adding a test case for this in derbynet.PreparedStatementTest.
> I am wondering if the community has any objection to one of the error message getting changed into another. I wonder if it will cause user applications to break because they rely of different error message. And if not, any ideas on which one we should get rid of?
> Also, the exception thrown for these 2 cases in Embedded server is same but it is not XCL14 or XCL13. I will work on entering another jira entry for difference in exception for embedded and network server.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.