[
https://issues.apache.org/jira/browse/DERBY-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739624#action_12739624
]
Kathey Marsden commented on DERBY-1191:
---------------------------------------
Lily helped me explore possible options for this issue (Thanks Lily!) .
Basically there seem to be two.
1) log the exception when the exception is created in SQLExceptionFactory and
SQLExceptionFactory40 getSQLException(). Adding a method
logException(SQLException se) to SQLExceptionFactory and calling it just
before returning the exception. The advantage to this approach is that it
requires a small amount of centralized code. The disadvantages are that it
requires access to the Monitor which seems a little out of place here. Also at
least in one case we create an exception that we normally never throw. In
EmbeddedConnection we have:
public static final SQLException NO_MEM =
Util.generateCsSQLException(SQLState.LOGIN_FAILED,
"java.lang.OutOfMemoryError");
and then only throw that if we run out of memory. There would have to be
special casing to handle this.
The side effect of logging from a Factory class seems a little odd.
2) Add a method to the Util class throwAndLogSQLException(SQLException se)
which logs the exception and then throws it. Then change the individual code
calls to instead of doing:
throw Util.generateCsSQLException(...);
to call
throwAndLog(Util.generateCsSQLException(...));
This seems clearer and the exception does not get logged until it is thrown.
The downside is that it changes a lot of code and it is possible some
exceptions might get missed. Developers need to be aware that for new
exceptions they need to call the method instead of just throwing the exception.
It might be tricky to backport to release branches since it would change so
much code.
I am really about split on the two options and welcome opinions or better ideas.
> 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: https://issues.apache.org/jira/browse/DERBY-1191
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Attachments: ReproDerby1191.java
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
