[
https://issues.apache.org/jira/browse/DERBY-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904516#comment-13904516
]
Kim Haase commented on DERBY-1997:
----------------------------------
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.)
> Misleading text in WwdEmbedded demo source file for Working With Derby
> ----------------------------------------------------------------------
>
> Key: DERBY-1997
> URL: https://issues.apache.org/jira/browse/DERBY-1997
> Project: Derby
> Issue Type: Bug
> Components: Demos/Scripts, Documentation
> Affects Versions: 10.2.1.6
> Reporter: Kim Haase
> Assignee: Kim Haase
> Priority: Minor
> Labels: derby_triage10_5_2
> Attachments: vcs-diff3523819486798216332.patch,
> vcs-diff7276709987551559550.patch
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
