Derby
  1. Derby
  2. DERBY-3913

mismatch between error XCL30 and 22003.S.4 and parameters in usage

    Details

    • Urgency:
      Normal
    • Issue & fix info:
      Newcomer

      Description

      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();

      -------------------------------------------

      1. exception-args.diff
        0.6 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Myrna van Lunteren created issue -
          Myrna van Lunteren made changes -
          Field Original Value New Value
          Affects Version/s 10.5.1.1 [ 12313771 ]
          Affects Version/s 10.5.0.0 [ 12313010 ]
          Dag H. Wanvik made changes -
          Issue & fix info [Newcomer]
          Hide
          Kristian Waagan added a comment -

          Triaged July 3, 2009: Assigned normal urgency.

          Show
          Kristian Waagan added a comment - Triaged July 3, 2009: Assigned normal urgency.
          Kristian Waagan made changes -
          Urgency Normal
          Kathey Marsden made changes -
          Labels derby_triage10_5_2
          Mamta A. Satoor made changes -
          Assignee Mamta A. Satoor [ mamtas ]
          Hide
          Mamta A. Satoor added a comment -

          The script generateClientMessageTest.sh which is supposed to generate a test to verify the correctness of the error messages is preety badly broken.I tried fixing the errors in the generated test but there were just too many problems in the generated test.

          I have checked in the fixes for the mismatch between error XCL30 and 22003.S.4 and parameters in usage though and hence this jira can be closed. There is another jira DERBY-1567 to fix the script when generates the test.

          Show
          Mamta A. Satoor added a comment - The script generateClientMessageTest.sh which is supposed to generate a test to verify the correctness of the error messages is preety badly broken.I tried fixing the errors in the generated test but there were just too many problems in the generated test. I have checked in the fixes for the mismatch between error XCL30 and 22003.S.4 and parameters in usage though and hence this jira can be closed. There is another jira DERBY-1567 to fix the script when generates the test.
          Hide
          Knut Anders Hatlen added a comment -

          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.

          Show
          Knut Anders Hatlen added a comment - 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.
          Knut Anders Hatlen made changes -
          Attachment exception-args.diff [ 12482529 ]
          Knut Anders Hatlen made changes -
          Link This issue is related to DERBY-3970 [ DERBY-3970 ]
          Mamta A. Satoor made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Mamta A. Satoor made changes -
          Fix Version/s 10.9.0.0 [ 12316344 ]
          Myrna van Lunteren made changes -
          Labels derby_triage10_5_2 derby_backport_reject_10_8 derby_triage10_5_2
          Hide
          Myrna van Lunteren added a comment - - edited

          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.
          Normally when we change a message we ought to remove it from the non-English locales (until a new translation) so the English gets picked up at run-time, but I don't think it's necessary in this case, because the behavior for those other languages remains the same as it was before the change.

          Show
          Myrna van Lunteren added a comment - - edited 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. Normally when we change a message we ought to remove it from the non-English locales (until a new translation) so the English gets picked up at run-time, but I don't think it's necessary in this case, because the behavior for those other languages remains the same as it was before the change.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12444151 ] Default workflow, editable Closed status [ 12802809 ]

            People

            • Assignee:
              Mamta A. Satoor
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development