db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2769) Implement error handling/parameter checking in Clob.setString
Date Wed, 22 Apr 2009 22:32:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701702#action_12701702
] 

Kathey Marsden commented on DERBY-2769:
---------------------------------------

Thank you Yun for the new patch. 
message change patch DERBY-2769-3-b.diff looks fine. I will run tests and check that in.


Clob.java

remove import  org.apache.derby.impl.jdbc.Util;
       This is unused and may bring engine code into the client which is not good.


For the condition below there are a few issues:
if (offset + len > str.length()) {
            throw new SqlException(agent_.logWriter_,
                    new ClientMessageId(
                            SQLState.LANG_SUBSTR_START_OR_LEN_OUT_OF_RANGE),
                    new Integer(offset), new Integer(len));
        }

Even though we are sharing a SQLState with  SQLState.LANG_SUBSTR_START_OR_LEN_OUT_OF_RANGE
we need a new message, because the existing one, "The second or third argument of the SUBSTR
function is out of range." doesn't make sense in this context and doesn't take parameters.
 I think the way to do this is add a new constant to SQLState.java with value "22011.S.1",
then add that message to messages.xml. The message should be something like: "The range specified
for the substring with offset {0} and len {1} is not valid".  There is another step too when
adding SQLState messages to the client.  They have to be added to java/build/org/apache/derbyBuild/splitmessages.java
to get picked up by the client build. Otherwise it will just print UNKOWN MESSAGE. After making
the changes, you may want to verify them manually or temporarily print out the message in
your JUnit test to make sure it all worked.  Unfortunately our JUnit tests just check SQLState
so can miss issues with message te
 xt.


ClobTest.java
There is a comment         
//if offset + len == str.length(), it's accepted.
I think this is incorrect and the test case below it useds str.length() -1

EmbedClob.java 
Again we should use a new message instead of LANG_SUBSTR_START_OR_LEN_OUT_OF_RANGE


I think the new checking causes some cases that used to execute to now fail with client. For
example I found I could execute setString(1,"goodbye",2,6) where the offset + len  were greater
than the length of the string before the change, but not after. I think the changes are ok
but we should probably have a release note.




> 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,
DERBY-2769-3-a.diff, DERBY-2769-3-a.stat, DERBY-2769-3-b.diff, DERBY-2769-3-b.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.


Mime
View raw message