[
https://issues.apache.org/jira/browse/DERBY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699347#action_12699347
]
Kathey Marsden commented on DERBY-2769:
---------------------------------------
Thank you Yun for the patch. Below are my comments.
ClobTest.java
Tests should use assertSQLState("<expected state>", sqle) to verify we got the
correct exception instead of assertTrue;
Clob.java
if (offset + len > str.length()) {
throw new SqlException(agent_.logWriter_,
new ClientMessageId(SQLState.BLOB_LENGTH_TOO_LONG),
new Integer(len));
}
For this condition we throw the exception
"The length specified '{0}' exceeds the size of the BLOB/BLOB."
but the actual problem is not the blob length but something like.
"The range specified for the substring with offset {0} and len {1} is not
valid"
We would need a new message for this, perhaps with SQLState 22011. You can
have multiple messages with the same SQLState.
BTW, I noticed the XJ079 message should say BLOB/CLOB not BLOB/BLOB. Could we
fix that as part of this issue?
I noticed another existing condition which doesn't look quite right.
if ((offset < 0) || offset > str.length() ) {
Should this be if ((offset < 0) || offset >= str.length() ) {
EmbedClob.java
same comments as client for the (offset + len > str.length()) and ((offset < 0)
|| offset > str.length() ) cases.
> Implement error handling/parameter checking in Clob.setString
> -------------------------------------------------------------
>
> Key: DERBY-2769
> URL: https://issues.apache.org/jira/browse/DERBY-2769
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.3.1.4
> Reporter: Kristian Waagan
> Assignee: Yun Lee
> Attachments: DERBY-2769-1.patch, DERBY-2769-1.stat,
> DERBY-2769-2.patch, DERBY-2769-2.stat
>
>
> The error handling, or parameter checking, in Clob.subString is not adequate.
> There are four parameters that can be invalid;
> * pos
> * str
> * offset
> * len
> The first one is already handled properly, the remaining three are not. They
> typically result in some low-level exception like a NPE.
> I have not found anything in the JDBC specification nor JavaDoc that dictates
> the behavior, except for that SQLException should use states defined in the
> SQL 2003 specification. A brief search there resulted in the following
> possibilities:
> 22003 - numeric value out of range
> 22004 - null value not allowed
> 2200F - zero-length character string
> 22011 - substring error
> 22023 - invalid parameter value
> Some of these are already defined by Derby, but with unsuitable or very
> specific error messages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
