[ 
https://issues.apache.org/jira/browse/DERBY-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Knut Anders Hatlen updated DERBY-3913:
--------------------------------------

    Attachment: exception-args.diff

The problem with XCL30.S seems to have been fixed in DERBY-3970, so now all 
exceptions with that message id are passed one argument and linked to the 
underlying IOException.

The fix committed here seems to have broken this in client.am.Lob. By changing 
the order of the arguments, we now pass two message arguments, and the 
generated SqlException is not linked to the underlying IOException. I suppose 
the confusion comes from the different signatures for the methods that create 
exceptions in the client and in the engine. In the engine, the cause should be 
passed before the message arguments, whereas it should be the last argument in 
the client.

The attached patch reverts that part of the fix for this issue.

Committed revision 1135404.

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

        

Reply via email to