[ http://issues.apache.org/jira/browse/DERBY-1191?page=comments#action_12373660 ]
Daniel John Debrunner commented on DERBY-1191: ---------------------------------------------- It's not clear to me that such exceptions belong in derby.log. Most exceptions that are a result of an application error (incorrect use of the JDBC api) do not end up in derby.log. E.g. calling ResultSet.getXXX when not on a row, calling a method on a closed JDBC object, calling ResultSet.getXXX with an out of range column identifier. I think derby.log should be reserved for errors that occur within the engine, not those at the JDBC api level. > Some SQLExceptions, for example those generated from BrokeredStatements, do > not print to derby.log even when derby.stream.error.logSeverityLevel=0 > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-1191 > URL: http://issues.apache.org/jira/browse/DERBY-1191 > Project: Derby > Type: Bug > Components: JDBC > Versions: 10.1.2.3, 10.2.0.0, 10.1.3.0 > Reporter: Kathey Marsden > Priority: Minor > > I found this when working on DERBY-1047. Exceptions thrown using > org.apache.derby.impl.jdbc.Util.generateCsSQLException() > do not print to derby.log even when derby.stream.error.logSeverityLevel=0 > For example the attached repro generates an expected exception but does not > print the error to the log. > java -Dderby.stream.error.logSeverityLevel=0 Derby1047 > This causes an expected exception to be thrown but it does not print to the > derby.log > 10.2.0.0 alpha > Apache Derby > Apache Derby Embedded JDBC Driver > done creating table > COL1 > ----------- > 1 > 2 > PASS: Expected Exception can'tholdable cusror in global xact:Cannot set > holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for a global transaction. > COL1 > ----------- > 1 > 2 > 3 > The code generating the exception is in > org.apache.derby.iapi.jdbc.BrokeredStatement > final void checkHoldability() throws SQLException { > int holdability = > controlCheck().checkHoldCursors(resultSetHoldability); > if (holdability != resultSetHoldability) > throw Util.generateCsSQLException(SQLState.CANNOT_HOLD_CURSOR_XA); > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
