Derby
  1. Derby
  2. DERBY-1997

Misleading text in WwdEmbedded demo source file for Working With Derby

    Details

    • Urgency:
      Normal

      Description

      I'm making some minor fixes to the Working With Derby manual (DERBY-1948, DERBY-1972). The description of the WwdEmbedded.java program in the HTML generated from the file rwwdactivity3.dita (http://db.apache.org/derby/docs/dev/workingwithderby/) contains the following paragraph:

      DERBY EXCEPTION REPORTING CLASSES: The two methods at the end of the file, errorPrint and SQLExceptionPrint, are generic exception reporting routines that can be used with any JDBC program. This type of exception handling is required because often multiple exceptions (SQLException) are chained together then thrown. A while loop is used to report on each error in the chain. These classes are used by calling the errorPrint method from the catch block of the code that accesses the database.

      The introductory text "DERBY EXCEPTION REPORTING CLASSES" is keyed to a comment with the same text in the DERBY_HOME/demo/programs/workingwithderby/WwdEmbedded.java program:

      // ## DERBY EXCEPTION REPORTING CLASSES ##

      /*** Exception reporting methods

        • with special handling of SQLExceptions

      ***/

      The problem is that there are no Derby exception reporting classes, only methods, as far as I can tell. The use of the term CLASSES is likely to confuse any users not well acquainted with Java (one of the target audiences of this manual). It would be great if someone could change CLASSES to METHODS in the WwdEmbedded.java file so that I can make the corresponding fix to the rwwdactivity3.dita file. I would also have to correct the confusing last sentence of the paragraph; I think it would make more sense to say, "The program starts this process by calling the errorPrint method from the catch block of the code that accesses the database." (I can't just change "classes" to "methods" because errorPrint is one of the methods.

      1. DERBY-1997.diff
        3 kB
        Kim Haase
      2. DERBY-1997.stat
        0.1 kB
        Kim Haase
      3. DERBY-1997-doc.diff
        8 kB
        Kim Haase
      4. DERBY-1997-doc.stat
        0.1 kB
        Kim Haase
      5. DERBY-1997-doc.zip
        8 kB
        Kim Haase
      6. vcs-diff3523819486798216332.patch
        2 kB
        Dyre Tjeldvoll
      7. vcs-diff7276709987551559550.patch
        2 kB
        Dyre Tjeldvoll

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          Working With Derby has now been merged with Getting Started with Derby (DERBY-2390), but the problematic text is still there - http://db.apache.org/derby/docs/dev/getstart/rwwdactivity3.html.

          One alternative way to fix it is to remove the exception reporting methods altogether (both from code and from docs). I think the reason why they were written in the first place, was that Java 1.3 didn't have initCause/getCause. But now those methods are available on all supported platforms, and we use them, so a simple call to printStackTrace() on the top-level exception should normally show the full exception chain.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2. Working With Derby has now been merged with Getting Started with Derby ( DERBY-2390 ), but the problematic text is still there - http://db.apache.org/derby/docs/dev/getstart/rwwdactivity3.html . One alternative way to fix it is to remove the exception reporting methods altogether (both from code and from docs). I think the reason why they were written in the first place, was that Java 1.3 didn't have initCause/getCause. But now those methods are available on all supported platforms, and we use them, so a simple call to printStackTrace() on the top-level exception should normally show the full exception chain.
          Hide
          Dyre Tjeldvoll added a comment -

          Removed the obsolete functions and used printStackTrace as suggested

          Show
          Dyre Tjeldvoll added a comment - Removed the obsolete functions and used printStackTrace as suggested
          Hide
          Dyre Tjeldvoll added a comment -

          Patch without white space diff

          Show
          Dyre Tjeldvoll added a comment - Patch without white space diff
          Hide
          Dag H. Wanvik added a comment -

          The last patch (by date) looks good to me +1.

          Hint: We usually use the .diff suffix,and intelligible names on the patch its self, e.g. derby-<issue>[-<partid>]-<rev>.diff. The <partid> is often omitted for simple issues, being called into service only for issues for which many incremental patches are needed. That said, exact usage varies among devs

          This makes it easier for reviewers that download many patches to keep track of them.

          Show
          Dag H. Wanvik added a comment - The last patch (by date) looks good to me +1. Hint: We usually use the .diff suffix,and intelligible names on the patch its self, e.g. derby-<issue> [-<partid>] -<rev>.diff. The <partid> is often omitted for simple issues, being called into service only for issues for which many incremental patches are needed. That said, exact usage varies among devs This makes it easier for reviewers that download many patches to keep track of them.
          Hide
          Dyre Tjeldvoll added a comment -

          Thanks for the review Dag.

          I didn't really like the names either, but that's what Netbeans does when exporting uncommitted changes to Jira. A neat feature, really, so I wonder if it is possible to configure the name it chooses for the patch... If not, I might be tempted to submit an enhancement request to NB. At least I was able to tell NB that I want to see white-space changes in diffs.

          Show
          Dyre Tjeldvoll added a comment - Thanks for the review Dag. I didn't really like the names either, but that's what Netbeans does when exporting uncommitted changes to Jira. A neat feature, really, so I wonder if it is possible to configure the name it chooses for the patch... If not, I might be tempted to submit an enhancement request to NB. At least I was able to tell NB that I want to see white-space changes in diffs.
          Hide
          Dag H. Wanvik added a comment -

          Right, I also use NetBeans but I haven't used that feature. I use command line "svn diff" (or git diff) to create the patches so I can choose the name of the patch file.
          If you could persuade the NB folks to let us customize patch names, that would be nice.

          Show
          Dag H. Wanvik added a comment - Right, I also use NetBeans but I haven't used that feature. I use command line "svn diff" (or git diff) to create the patches so I can choose the name of the patch file. If you could persuade the NB folks to let us customize patch names, that would be nice.
          Hide
          ASF subversion and git services added a comment -

          Commit 1496870 from Dyre Tjeldvoll
          [ https://svn.apache.org/r1496870 ]

          DERBY-1997: Remove custom exception printing methods and replace with printStackTrace as suggested

          Show
          ASF subversion and git services added a comment - Commit 1496870 from Dyre Tjeldvoll [ https://svn.apache.org/r1496870 ] DERBY-1997 : Remove custom exception printing methods and replace with printStackTrace as suggested
          Hide
          Kim Haase added a comment -

          Thanks a lot, Dyre, for making these fixes. Did you notice there is also a WwdClientExample.java file that also should have those methods removed?

          Also, a comment still refers to the errorPrint method.

          One main purpose of the two functions was to provide some helpful output if the exception is a SQLException. I wonder if the catch clause could include this output for SQLExceptions and use printStackTrace for other exceptions.

          Show
          Kim Haase added a comment - Thanks a lot, Dyre, for making these fixes. Did you notice there is also a WwdClientExample.java file that also should have those methods removed? Also, a comment still refers to the errorPrint method. One main purpose of the two functions was to provide some helpful output if the exception is a SQLException. I wonder if the catch clause could include this output for SQLExceptions and use printStackTrace for other exceptions.
          Hide
          Kim Haase added a comment -

          I just happened to notice, while working on DERBY-6236, that this issue has not been resolved. The error-reporting methods mentioned in the Getting Started topic that describes the WwdEmbedded program were removed from the java/demo/workingwithderby/WwdEmbedded.java file and replaced with a call to e.printStacktrace (which should probably be replaced with a proper logging call nowadays). However, the corresponding changes were not subsequently made to the java/demo/workingwithderby/WwdClientExample.java file or to the Getting Started topic.

          Show
          Kim Haase added a comment - I just happened to notice, while working on DERBY-6236 , that this issue has not been resolved. The error-reporting methods mentioned in the Getting Started topic that describes the WwdEmbedded program were removed from the java/demo/workingwithderby/WwdEmbedded.java file and replaced with a call to e.printStacktrace (which should probably be replaced with a proper logging call nowadays). However, the corresponding changes were not subsequently made to the java/demo/workingwithderby/WwdClientExample.java file or to the Getting Started topic.
          Hide
          Kim Haase added a comment -

          I also notice that the Developer's Guide topic "Example of processing SQLExceptions" (http://db.apache.org/derby/docs/10.10/devguide/rdevprocsqle.html) describes error-reporting methods similar to those in the Working with Derby example.

          We probably do want to call printStackTrace after all to get the full exception chain.

          Show
          Kim Haase added a comment - I also notice that the Developer's Guide topic "Example of processing SQLExceptions" ( http://db.apache.org/derby/docs/10.10/devguide/rdevprocsqle.html ) describes error-reporting methods similar to those in the Working with Derby example. We probably do want to call printStackTrace after all to get the full exception chain.
          Hide
          Kim Haase added a comment -

          The behavior of the client example is different from that of the embedded example. When I run the embedded example, the printStackTrace call reports the SQLSTATE value (22001) in the exception chain.

          java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source)
          ...
          Caused by: java.sql.SQLException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
          at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source)
          ... 11 more
          Caused by: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)

          When I run the client example, the SQLSTATE error does not appear:

          java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
          ...
          Caused by: org.apache.derby.client.am.SqlException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          at org.apache.derby.client.am.Statement.completeExecute(Unknown Source)
          at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown Source)

          So maybe the error-printing methods should be left in the client example after all. It would be nice to know why this happens, though.

          (I'm running against a 10.10.1.1 installation because I get an upgrade error trying to run the client example against a 10.11 build. I can't think why, since the embedded example, with derby.jar instead of derbyclient.jar in the classpath, works fine.)

          Show
          Kim Haase added a comment - The behavior of the client example is different from that of the embedded example. When I run the embedded example, the printStackTrace call reports the SQLSTATE value (22001) in the exception chain. java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) ... Caused by: java.sql.SQLException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ... 11 more Caused by: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) When I run the client example, the SQLSTATE error does not appear: java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source) ... Caused by: org.apache.derby.client.am.SqlException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.client.am.Statement.completeExecute(Unknown Source) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(Unknown Source) So maybe the error-printing methods should be left in the client example after all. It would be nice to know why this happens, though. (I'm running against a 10.10.1.1 installation because I get an upgrade error trying to run the client example against a 10.11 build. I can't think why, since the embedded example, with derby.jar instead of derbyclient.jar in the classpath, works fine.)
          Hide
          Knut Anders Hatlen added a comment -

          I think the difference is that iapi.error.StandardException in embedded overrides toString() and prepends the SQLState to the error message, whereas client.am.SqlException simply inherits Throwable.toString(). I suppose we could harmonize the two.

          Show
          Knut Anders Hatlen added a comment - I think the difference is that iapi.error.StandardException in embedded overrides toString() and prepends the SQLState to the error message, whereas client.am.SqlException simply inherits Throwable.toString(). I suppose we could harmonize the two.
          Hide
          Kim Haase added a comment -

          Thanks for the explanation! I guess that should be a separate issue, though. Should I file it or should you?

          Show
          Kim Haase added a comment - Thanks for the explanation! I guess that should be a separate issue, though. Should I file it or should you?
          Hide
          Knut Anders Hatlen added a comment -

          I've filed DERBY-6484.

          Show
          Knut Anders Hatlen added a comment - I've filed DERBY-6484 .
          Hide
          Kim Haase added a comment -

          Thanks, Knut, for filing DERBY-6484 to reconcile the exception reporting behavior. Perhaps I should document the hoped-for behavior instead of the current behavior ...

          Show
          Kim Haase added a comment - Thanks, Knut, for filing DERBY-6484 to reconcile the exception reporting behavior. Perhaps I should document the hoped-for behavior instead of the current behavior ...
          Hide
          Knut Anders Hatlen added a comment -

          I've also filed DERBY-6488 to get rid of the extra EmbedSQLException in the exception chain on the embedded driver (it masquerades as a plain java.sql.SQLException in the stack trace by overriding toString() and replacing the internal class name).

          On embedded the chain looks like this: SQLDataException -> EmbedSQLException -> StandardException
          The client has a simpler chain: SQLDataException -> SqlException

          That's probably going to be more work than the fix in the toString() method, though.

          Show
          Knut Anders Hatlen added a comment - I've also filed DERBY-6488 to get rid of the extra EmbedSQLException in the exception chain on the embedded driver (it masquerades as a plain java.sql.SQLException in the stack trace by overriding toString() and replacing the internal class name). On embedded the chain looks like this: SQLDataException -> EmbedSQLException -> StandardException The client has a simpler chain: SQLDataException -> SqlException That's probably going to be more work than the fix in the toString() method, though.
          Hide
          Kim Haase added a comment -

          I notice that even though DERBY-6484 and DERBY-6488 have been fixed, the discrepancy in error reporting between the Getting Started embedded and client examples still exists (3 exceptions from embedded, 2 from client). I built a new version of Derby after running svn update, but I seem to get the same exceptions as before (I never did get EmbedSQLException). It doesn't look as if DERBY-6493 is likely to resolve this discrepancy. Is there anything else that might?

          Show
          Kim Haase added a comment - I notice that even though DERBY-6484 and DERBY-6488 have been fixed, the discrepancy in error reporting between the Getting Started embedded and client examples still exists (3 exceptions from embedded, 2 from client). I built a new version of Derby after running svn update, but I seem to get the same exceptions as before (I never did get EmbedSQLException). It doesn't look as if DERBY-6493 is likely to resolve this discrepancy. Is there anything else that might?
          Hide
          Knut Anders Hatlen added a comment -

          Hi Kim,

          What code are you running when you see the differing exceptions? When I run the WwdEmbedded and WwdClientExample classes in the java/demo directory using head of trunk, I see these exceptions:

          % java WwdEmbedded
          Connected to database jdbcDemoDB
          Enter wish-list item (enter exit to end): 
          I wish to see a Java program fail
           . . . exception thrown:
          java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          	at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:83)
          	at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:233)
          	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424)
          	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353)
          	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2396)
          	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82)
          	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1430)
          	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709)
          	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(EmbedPreparedStatement.java:320)
          	at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309)
          	at WwdEmbedded.main(WwdEmbedded.java:85)
          Caused by: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290)
          	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:285)
          	at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(SQLChar.java:1846)
          	at org.apache.derby.iapi.types.SQLVarchar.normalize(SQLVarchar.java:181)
          	at org.apache.derby.iapi.types.SQLVarchar.normalize(SQLVarchar.java:158)
          	at org.apache.derby.iapi.types.DataTypeDescriptor.normalize(DataTypeDescriptor.java:647)
          	at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeColumn(NormalizeResultSet.java:332)
          	at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeRow(NormalizeResultSet.java:376)
          	at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:191)
          	at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:142)
          	at org.apache.derby.impl.sql.execute.InsertResultSet.getNextRowCore(InsertResultSet.java:1175)
          	at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:453)
          	at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:470)
          	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:349)
          	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1338)
          	... 4 more
          Getting Started With Derby JDBC program ending.
          
          % java WwdClientExample
          Connected to database jdbcDemoDB
           . . . . creating table WISH_LIST
          Enter wish-list item (enter exit to end): 
          I wish to see a Java program fail
           . . . exception thrown:
          
          ---SQLException Caught---
          
          SQLState:   22001
          Severity: 30000
          Message:  A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          	at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:72)
          	at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:321)
          	at org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:404)
          	at WwdClientExample.main(WwdClientExample.java:81)
          Caused by: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32.
          	at org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1861)
          	at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323)
          	at org.apache.derby.client.net.NetStatementReply.readExecute(NetStatementReply.java:72)
          	at org.apache.derby.client.net.StatementReply.readExecute(StatementReply.java:59)
          	at org.apache.derby.client.net.NetPreparedStatement.readExecute_(NetPreparedStatement.java:167)
          	at org.apache.derby.client.am.ClientPreparedStatement.readExecute(ClientPreparedStatement.java:1842)
          	at org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2129)
          	at org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:409)
          	at org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:395)
          	... 1 more
          Getting Started With Derby JDBC program ending.
          

          Both chains have two exceptions.

          Show
          Knut Anders Hatlen added a comment - Hi Kim, What code are you running when you see the differing exceptions? When I run the WwdEmbedded and WwdClientExample classes in the java/demo directory using head of trunk, I see these exceptions: % java WwdEmbedded Connected to database jdbcDemoDB Enter wish-list item (enter exit to end): I wish to see a Java program fail . . . exception thrown: java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:83) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:233) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:424) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:353) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:2396) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:82) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1430) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1709) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeLargeUpdate(EmbedPreparedStatement.java:320) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeUpdate(EmbedPreparedStatement.java:309) at WwdEmbedded.main(WwdEmbedded.java:85) Caused by: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:290) at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:285) at org.apache.derby.iapi.types.SQLChar.hasNonBlankChars(SQLChar.java:1846) at org.apache.derby.iapi.types.SQLVarchar.normalize(SQLVarchar.java:181) at org.apache.derby.iapi.types.SQLVarchar.normalize(SQLVarchar.java:158) at org.apache.derby.iapi.types.DataTypeDescriptor.normalize(DataTypeDescriptor.java:647) at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeColumn(NormalizeResultSet.java:332) at org.apache.derby.impl.sql.execute.NormalizeResultSet.normalizeRow(NormalizeResultSet.java:376) at org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(NormalizeResultSet.java:191) at org.apache.derby.impl.sql.execute.DMLWriteResultSet.getNextRowCore(DMLWriteResultSet.java:142) at org.apache.derby.impl.sql.execute.InsertResultSet.getNextRowCore(InsertResultSet.java:1175) at org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:453) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:470) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:349) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1338) ... 4 more Getting Started With Derby JDBC program ending. % java WwdClientExample Connected to database jdbcDemoDB . . . . creating table WISH_LIST Enter wish-list item (enter exit to end): I wish to see a Java program fail . . . exception thrown: ---SQLException Caught--- SQLState: 22001 Severity: 30000 Message: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. java.sql.SQLDataException: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.client.am.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:72) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:321) at org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:404) at WwdClientExample.main(WwdClientExample.java:81) Caused by: ERROR 22001: A truncation error was encountered trying to shrink VARCHAR 'I wish to see a Java program fail' to length 32. at org.apache.derby.client.am.ClientStatement.completeExecute(ClientStatement.java:1861) at org.apache.derby.client.net.NetStatementReply.parseEXCSQLSTTreply(NetStatementReply.java:323) at org.apache.derby.client.net.NetStatementReply.readExecute(NetStatementReply.java:72) at org.apache.derby.client.net.StatementReply.readExecute(StatementReply.java:59) at org.apache.derby.client.net.NetPreparedStatement.readExecute_(NetPreparedStatement.java:167) at org.apache.derby.client.am.ClientPreparedStatement.readExecute(ClientPreparedStatement.java:1842) at org.apache.derby.client.am.ClientPreparedStatement.flowExecute(ClientPreparedStatement.java:2129) at org.apache.derby.client.am.ClientPreparedStatement.executeUpdateX(ClientPreparedStatement.java:409) at org.apache.derby.client.am.ClientPreparedStatement.executeUpdate(ClientPreparedStatement.java:395) ... 1 more Getting Started With Derby JDBC program ending. Both chains have two exceptions.
          Hide
          Kim Haase added a comment -

          I've been using JDK 6u45 on Solaris, not the most usual platform, I suppose. I'll try it again and also try updating to JDK 7.

          Show
          Kim Haase added a comment - I've been using JDK 6u45 on Solaris, not the most usual platform, I suppose. I'll try it again and also try updating to JDK 7.
          Hide
          Kim Haase added a comment -

          You are quite right, Knut – I must have had a bad classpath somewhere when I ran it before. I just get two errors now from both versions. I will file a patch to remove the old-fashioned error handling from the client example and update the comments in both.

          Thanks for your forbearance.

          Show
          Kim Haase added a comment - You are quite right, Knut – I must have had a bad classpath somewhere when I ran it before. I just get two errors now from both versions. I will file a patch to remove the old-fashioned error handling from the client example and update the comments in both. Thanks for your forbearance.
          Hide
          Kim Haase added a comment -

          Attaching DERBY-1997.diff and DERBY-1997.stat, removing the old-fashioned error-printing methods from the client example and updating the comments in both the client and embedded examples.

          M java/demo/workingwithderby/WwdEmbedded.java
          M java/demo/workingwithderby/WwdClientExample.java

          A follow-on patch will be needed to update the Getting Started manual.

          Show
          Kim Haase added a comment - Attaching DERBY-1997 .diff and DERBY-1997 .stat, removing the old-fashioned error-printing methods from the client example and updating the comments in both the client and embedded examples. M java/demo/workingwithderby/WwdEmbedded.java M java/demo/workingwithderby/WwdClientExample.java A follow-on patch will be needed to update the Getting Started manual.
          Hide
          Kim Haase added a comment -

          Is there any point in keeping the "Example of processing SQLExceptions" topic in the Developer's Guide (http://db.apache.org/derby/docs/10.10/devguide/rdevprocsqle.html)? It uses the same mechanism that the Working with Derby examples used to process the exceptions – going through the exception chain using getNextException().

          The NATIVE authentication example in "NATIVE authentication and SQL authorization example" does too (http://db.apache.org/derby/docs/10.10/devguide/rdevcsecurenativeauthex.html).

          Thanks for any advice.

          Show
          Kim Haase added a comment - Is there any point in keeping the "Example of processing SQLExceptions" topic in the Developer's Guide ( http://db.apache.org/derby/docs/10.10/devguide/rdevprocsqle.html)? It uses the same mechanism that the Working with Derby examples used to process the exceptions – going through the exception chain using getNextException(). The NATIVE authentication example in "NATIVE authentication and SQL authorization example" does too ( http://db.apache.org/derby/docs/10.10/devguide/rdevcsecurenativeauthex.html ). Thanks for any advice.
          Hide
          Knut Anders Hatlen added a comment -

          In most cases I believe that going through the chain using getNextException() isn't going to give more information than printStackTrace(), but there still are some cases where printStackTrace() won't show all exceptions that getNextException() would. That's typically when Derby continues processing after an error, and reports all errors at the end. See for example SystemProcedures.rollBackAndThrowSQLException().

          Show
          Knut Anders Hatlen added a comment - In most cases I believe that going through the chain using getNextException() isn't going to give more information than printStackTrace(), but there still are some cases where printStackTrace() won't show all exceptions that getNextException() would. That's typically when Derby continues processing after an error, and reports all errors at the end. See for example SystemProcedures.rollBackAndThrowSQLException().
          Hide
          Kim Haase added a comment -

          Thanks for that clarification, Knut. So it probably makes sense to remove those methods from Getting Started for the sake of simplicity, but to leave them in the Developer's Guide (possibly with an explanation).

          Show
          Kim Haase added a comment - Thanks for that clarification, Knut. So it probably makes sense to remove those methods from Getting Started for the sake of simplicity, but to leave them in the Developer's Guide (possibly with an explanation).
          Hide
          Kim Haase added a comment -

          Attaching DERBY-1997-doc.diff, DERBY-1997-doc.stat, and DERBY-1997-doc.zip, with documentation changes as follows:

          M src/getstart/rwwdactivity3.dita
          M src/devguide/cdevconcepts844813.dita
          M src/devguide/rdevprocsqle.dita

          The corrections to cdevconcepts844813.dita are mainly for formatting.

          Please let me know what additional changes are needed in either the code or the doc patch. Thanks!

          Show
          Kim Haase added a comment - Attaching DERBY-1997 -doc.diff, DERBY-1997 -doc.stat, and DERBY-1997 -doc.zip, with documentation changes as follows: M src/getstart/rwwdactivity3.dita M src/devguide/cdevconcepts844813.dita M src/devguide/rdevprocsqle.dita The corrections to cdevconcepts844813.dita are mainly for formatting. Please let me know what additional changes are needed in either the code or the doc patch. Thanks!
          Hide
          Knut Anders Hatlen added a comment -

          Thank you, Kim. These changes look good to me. +1 to commit.

          Show
          Knut Anders Hatlen added a comment - Thank you, Kim. These changes look good to me. +1 to commit.
          Hide
          ASF subversion and git services added a comment -

          Commit 1576342 from Kim Haase in branch 'code/trunk'
          [ https://svn.apache.org/r1576342 ]

          DERBY-1997 Misleading text in WwdEmbedded demo source file for Working With Derby

          Modified two demo source files to make embedded and client error handling identical.

          Patch: DERBY-1997.diff

          Show
          ASF subversion and git services added a comment - Commit 1576342 from Kim Haase in branch 'code/trunk' [ https://svn.apache.org/r1576342 ] DERBY-1997 Misleading text in WwdEmbedded demo source file for Working With Derby Modified two demo source files to make embedded and client error handling identical. Patch: DERBY-1997 .diff
          Hide
          ASF subversion and git services added a comment -

          Commit 1576358 from Kim Haase in branch 'docs/trunk'
          [ https://svn.apache.org/r1576358 ]

          DERBY-1997 Misleading text in WwdEmbedded demo source file for Working With Derby

          Modified two Developer's Guide topics and one Getting Started topic.

          Patch: DERBY-1997-doc.diff

          Show
          ASF subversion and git services added a comment - Commit 1576358 from Kim Haase in branch 'docs/trunk' [ https://svn.apache.org/r1576358 ] DERBY-1997 Misleading text in WwdEmbedded demo source file for Working With Derby Modified two Developer's Guide topics and one Getting Started topic. Patch: DERBY-1997 -doc.diff
          Hide
          Kim Haase added a comment -

          Thanks, Knut!

          Committed patch DERBY-1997.diff to code trunk at revision 1576342.

          Committed patch DERBY-1997-doc.diff to documentation trunk at revision 1576358.

          It might be possible to backport the fixes to 10.10 (at least), but since the issue is minor and was rediscovered in the course of 10.11 work that changed some of the files involved, I don't see a need to do so. I am open to persuasion, though.

          Show
          Kim Haase added a comment - Thanks, Knut! Committed patch DERBY-1997 .diff to code trunk at revision 1576342. Committed patch DERBY-1997 -doc.diff to documentation trunk at revision 1576358. It might be possible to backport the fixes to 10.10 (at least), but since the issue is minor and was rediscovered in the course of 10.11 work that changed some of the files involved, I don't see a need to do so. I am open to persuasion, though.

            People

            • Assignee:
              Kim Haase
              Reporter:
              Kim Haase
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development