Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #37106 > unrolled thread

Not closing a SQL(ite3) connection

Back to article view | Back to comp.lang.java.programmer

Contents

  Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 11:28 +0200
    Re: Not closing a SQL(ite3) connection Arne Vajhøj <arne@vajhoej.dk> - 2017-08-09 18:00 -0400
      Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-11 10:26 +0200
        Re: Not closing a SQL(ite3) connection Arne Vajhøj <arne@vajhoej.dk> - 2017-08-11 20:27 -0400
          Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 10:00 +0200
            Re: Not closing a SQL(ite3) connection Andreas Leitgeb <avl@logic.at> - 2017-08-12 08:51 +0000
              Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 11:05 +0200
            Re: Not closing a SQL(ite3) connection Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 09:52 -0400
              Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 16:26 +0200
                Re: Not closing a SQL(ite3) connection Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 21:43 -0400
                  Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-15 08:19 +0200
            Re: Not closing a SQL(ite3) connection lewbloch@gmail.com - 2017-08-12 10:14 -0700
          Re: Not closing a SQL(ite3) connection Andreas Leitgeb <avl@logic.at> - 2017-08-12 09:33 +0000
            Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 12:57 +0200
              Re: Not closing a SQL(ite3) connection Andreas Leitgeb <avl@logic.at> - 2017-08-12 13:27 +0000
                Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 16:37 +0200
              Re: Not closing a SQL(ite3) connection Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 09:55 -0400
                Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-12 16:44 +0200
                  Re: Not closing a SQL(ite3) connection Arne Vajhøj <arne@vajhoej.dk> - 2017-08-12 21:45 -0400
              Re: Not closing a SQL(ite3) connection Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-12 21:04 +0000
                Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 00:30 +0200
                  Re: Not closing a SQL(ite3) connection Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-13 11:34 +0000
                    Re: Not closing a SQL(ite3) connection Cecil Westerhof <Cecil@decebal.nl> - 2017-08-13 15:27 +0200
            Re: Not closing a SQL(ite3) connection Andreas Leitgeb <avl@logic.at> - 2017-08-12 13:06 +0000

Page 2 of 2 — ← Prev page 1 [2]

#37155

Martin Gregorie <martin@address-in-sig.invalid> writes:

> On Sat, 12 Aug 2017 12:57:40 +0200, Cecil Westerhof wrote:
>
>> The String will be done with a variable of-course. Beside that: is the
>> code OK, or can it be improved?
>>
> The main one is that with most JDBC drivers, the SQLException that 
> try...catch intercepts is merely the first SQLEXception in a chain of 
> SQLExceptions. You miss a lot of information about what went wrong by not 
> repeatedly calling the current SQLException's getNextException() method 
> until all members of the chain have been retrieved and their contents 
> displayed. Alternatively, call SQLException.iterator and use that to 
> iterate through the SQLException chain.
>   
> If the SQL query was at all complex then the first exception in the chain 
> may not be particularly helpful because what caused the query to fail is 
> described further down the chain.

On a tip from Arne I already changed the code to:
    @Override
    public void close() throws SQLException {
        Statement stmt;

        if (isClosed) {
            throw new SQLException("SQLResultSet is already closed.");
        }
        stmt     = resultSet.getStatement();
        resultSet.close();
        stmt.close();
        isClosed = true;
    }

That solves this problem?

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37175

On Sun, 13 Aug 2017 00:30:14 +0200, Cecil Westerhof wrote:

> Martin Gregorie <martin@address-in-sig.invalid> writes:
> 
>> On Sat, 12 Aug 2017 12:57:40 +0200, Cecil Westerhof wrote:
>>
>>> The String will be done with a variable of-course. Beside that: is the
>>> code OK, or can it be improved?
>>>
>> The main one is that with most JDBC drivers, the SQLException that
>> try...catch intercepts is merely the first SQLEXception in a chain of
>> SQLExceptions. You miss a lot of information about what went wrong by
>> not repeatedly calling the current SQLException's getNextException()
>> method until all members of the chain have been retrieved and their
>> contents displayed. Alternatively, call SQLException.iterator and use
>> that to iterate through the SQLException chain.
>>   
>> If the SQL query was at all complex then the first exception in the
>> chain may not be particularly helpful because what caused the query to
>> fail is described further down the chain.
> 
> On a tip from Arne I already changed the code to:
>     @Override public void close() throws SQLException {
>         Statement stmt;
> 
>         if (isClosed) {
>             throw new SQLException("SQLResultSet is already closed.");
>         }
>         stmt     = resultSet.getStatement();
>         resultSet.close();
>         stmt.close();
>         isClosed = true;
>     }
> 
> That solves this problem?

No, not really: the chain of SQLExceptions can be quite similar in 
content to a stack trace in that the first one or two exceptions just say 
that an error was encountered but not what caused it: you have to look 
further down the chain to see what actually failed, causing the first few 
entries in the chain to report failure. You need to look at the whole 
chain to work out what caused the error, which may be at the DB schema 
level, i.e. not necessarily a problem in the application code, but rather 
a mismatch between the application's requirements and the DB schema.
 
In fairly complex non-interactive applications I tend to make the 
application classes/methods further up the stack than JDBC operations 
rethrow SQLExceptions, only catching them in main() and making that catch 
report the entire SQLException chain before terminating the application. 
This works because in well-designed and debugged JDBC applications the 
SQLEXception chain will be reporting failures at the level of the JDBC's 
RDBMS-specific driver or below. During unit testing and debugging it also 
gives you almost exactly what you need to unambiguously locate the error, 
especially if your catch code also dumps a stacktrace.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#37177

Martin Gregorie <martin@address-in-sig.invalid> writes:

>> On a tip from Arne I already changed the code to:
>>     @Override public void close() throws SQLException {
>>         Statement stmt;
>> 
>>         if (isClosed) {
>>             throw new SQLException("SQLResultSet is already closed.");
>>         }
>>         stmt     = resultSet.getStatement();
>>         resultSet.close();
>>         stmt.close();
>>         isClosed = true;
>>     }
>> 
>> That solves this problem?
>
> No, not really: the chain of SQLExceptions can be quite similar in 
> content to a stack trace in that the first one or two exceptions just say 
> that an error was encountered but not what caused it: you have to look 
> further down the chain to see what actually failed, causing the first few 
> entries in the chain to report failure. You need to look at the whole 
> chain to work out what caused the error, which may be at the DB schema 
> level, i.e. not necessarily a problem in the application code, but rather 
> a mismatch between the application's requirements and the DB schema.
>  
> In fairly complex non-interactive applications I tend to make the 
> application classes/methods further up the stack than JDBC operations 
> rethrow SQLExceptions, only catching them in main() and making that catch 
> report the entire SQLException chain before terminating the application. 
> This works because in well-designed and debugged JDBC applications the 
> SQLEXception chain will be reporting failures at the level of the JDBC's 
> RDBMS-specific driver or below. During unit testing and debugging it also 
> gives you almost exactly what you need to unambiguously locate the error, 
> especially if your catch code also dumps a stacktrace.

OK, I will implement that.

-- 
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[toc] | [prev] | [next] | [standalone]

#37143

The exception's message alone might not even be enough for analysis:
either make sure to also print the StackTrace, or add manual tracing
info like as follows: (only for simple experiments like this; real code
should just log the complete stacktrace, or there'd be the risk that
the where-labels eventually bit-rot out of sync and turn to become
actively misleading):

             String where;

>>>          try {

                 where = "stmt.close";

>>>              stmt.close();

                 where = "rs.next";

>>>              resultSet.next();

                 where = "rs.close";

>>>              resultSet.close();
>>>          } catch (SQLException e) {

                 errorMsg += e.getMessage() + "\n where=" + where + "\n";

>>>              System.out.println(errorMsg);
>>>          }
> Also, it might be better to actually add the exception information
> rather than a hardcoded string to errorMsg. Unless you really ran it 
> in the debugger and examined e, you wouldn't know, what really 
> threw the exception.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web