Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1855305436.1238412170678.JavaMail.jira@brutus>
Date: Mon, 30 Mar 2009 04:22:50 -0700 (PDT)
From: "Kristian Waagan (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2769) Implement error handling/parameter
 checking in Clob.setString
In-Reply-To: <31684687.1181131825855.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Kristian Waagan commented on DERBY-2769:
----------------------------------------

BTW, the current patch doesn't compile in my sandbox (due to an import). The import also looks incorrect, as it introduces a dependency from the product jar (derby.jar) to the testing jar.

To catch issues like this, the 'clobber' target should be run prior to the compile targets. This target makes sure your patch can be compiled from scratch, with no existing class files lying around etc.

Thanks,

> 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
>
>
> 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.