Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 29 Jun 2011 18:02:29 +0000 (UTC)
From: "Myrna van Lunteren (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <2082154766.3204.1309370549090.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-3913) mismatch between error XCL30 and
 22003.S.4 and parameters in usage
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Myrna van Lunteren commented on DERBY-3913:
-------------------------------------------

Added a reject backport 10.8 because the remaining change changed the construction of the message, and the translations were recently contributed for 10.8.
I don't think it's necessary to eliminate the message from other languages, because the behavior for those remains the same as it is currently. 

> mismatch between error XCL30 and 22003.S.4 and parameters in usage
> ------------------------------------------------------------------
>
>                 Key: DERBY-3913
>                 URL: https://issues.apache.org/jira/browse/DERBY-3913
>             Project: Derby
>          Issue Type: Bug
>          Components: Miscellaneous
>    Affects Versions: 10.5.1.1
>            Reporter: Myrna van Lunteren
>            Assignee: Mamta A. Satoor
>            Priority: Trivial
>              Labels: derby_backport_reject_10_8, derby_triage10_5_2
>             Fix For: 10.9.0.0
>
>         Attachments: exception-args.diff
>
>
> I found a script, trunk/tools/testing/i18nTestGenerator/generateClientMessageTest.sh, intended to create a test to verify correctness of client error messages(trunk/java/testing/org/apache/derbyTesting/functionTests/tests/i18n/TestClientMessages.java ). 
> The script is broken (see DERBY-1567) but after fixing up the resulting test and running it, it did show two messages which look a little odd in their usage (plus some messages for which the usage looked fine):
>                                                             
> XCL30 - LANG_STREAMING_COLUMN_I_O_EXCEPTION: 
> messages.xml: 
>             <msg>
>                 <name>XCL30.S</name>
>                 <text>An IOException was thrown when reading a '{0}' from an InputStream.</text>
>                 <arg>value</arg>
>             </msg>
> apparently correct number of parameters, but odd...doesn't look like ioe fits the usage in the message text.
> EmbedBlob:
>             } catch (IOException ioe) {
>                 throw StandardException.newException(
>                         SQLState.LANG_STREAMING_COLUMN_I_O_EXCEPTION, ioe);
>             }
> has a second parameter:
> client.am.Lob:
>             throw new SqlException(null,
>                         new ClientMessageId(
>                             SQLState.LANG_STREAMING_COLUMN_I_O_EXCEPTION),
>                         typeDesc,
>                         ioe
>                     );
> looks like second parameter fits the {0}:
> SQLBinary: 
> 		throw StandardException.
> 			newException(SQLState.LANG_STREAMING_COLUMN_I_O_EXCEPTION,
> 						 ioe, getTypeName());
> SQLChar:
> 		throw StandardException.
> 			newException(SQLState.LANG_STREAMING_COLUMN_I_O_EXCEPTION,
> 						 ioe, getTypeName());
>                    throw StandardException.newException(
>                             SQLState.LANG_STREAMING_COLUMN_I_O_EXCEPTION, 
>                             ioe, 
>                             "java.sql.String");
> --------------------------------------------------------------
> 22003.S.4 - CLIENT_LENGTH_OUTSIDE_RANGE_FOR_DATATYPE
>             <msg>
>                 <name>22003.S.4</name>
>                 <text>The length ({0}) exceeds the maximum length for the data type ({1}).</text>
>                 <arg>number</arg>
>                 <arg>datatypeName</arg>
>             </msg>
> correct number of parameters, but new Integer(Integer.MAX_VALUE) returns a number, not a datatype name:             
> client.am.PreparedStatement:
> 		throw new SqlException(
>                         agent_.logWriter_,
>                         new ClientMessageId(
>                             SQLState.CLIENT_LENGTH_OUTSIDE_RANGE_FOR_DATATYPE),
>                         new Long(length),
>                         new Integer(Integer.MAX_VALUE)
>                     ).getSQLException();
> client.am.ResultSet:
>                 throw new SqlException(agent_.logWriter_,
>                     new ClientMessageId(SQLState.CLIENT_LENGTH_OUTSIDE_RANGE_FOR_DATATYPE),
>                     new Long(length), new Integer(Integer.MAX_VALUE)).getSQLException();
>                 throw new SqlException(agent_.logWriter_,
>                     new ClientMessageId(SQLState.CLIENT_LENGTH_OUTSIDE_RANGE_FOR_DATATYPE),
>                     new Long(length), new Integer(Integer.MAX_VALUE)).getSQLException();                
> 		throw new SqlException(agent_.logWriter_,
>                     new ClientMessageId(SQLState.CLIENT_LENGTH_OUTSIDE_RANGE_FOR_DATATYPE),
>                     new Long(length), new Integer(Integer.MAX_VALUE)).getSQLException();
> -------------------------------------------

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira