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.

Reply via email to