db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-1191) Some SQLExceptions, for example those generated from BrokeredStatements, do not print to derby.log even when derby.stream.error.logSeverityLevel=0
Date Wed, 05 Aug 2009 17:15:14 GMT

    [ 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.


Mime
View raw message