Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Cecil Westerhof <Cecil@decebal.nl>
Newsgroups: comp.lang.java.programmer
Subject: Re: Not closing a SQL(ite3) connection
Date: Sat, 12 Aug 2017 16:26:22 +0200
Organization: Decebal Computing
Lines: 95
Message-ID: <877ey8zwtt.fsf@munus.decebal.nl>
References: <87a839um2q.fsf@munus.decebal.nl> <omg0la$1qe3$1@gioia.aioe.org> <874lte1pdj.fsf@munus.decebal.nl> <omli1h$jt7$1@gioia.aioe.org> <87k229z041.fsf@munus.decebal.nl> <omn168$mgs$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="a1c8c080b2cb6129343ef73ef98e693f"; logging-data="381"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vStTa8AEFjD1tosYhtTD3FaiYyJpCJcA="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Cancel-Lock: sha1:3+qN4lNAvhLnehrIMOOQbmo1btM= sha1:NWPCrJgZLPAVBrTk+FKJq1amWwI=
X-Homepage: http://www.decebal.nl/
Xref: csiph.com comp.lang.java.programmer:37147

Arne Vajhøj <arne@vajhoej.dk> writes:

> I got that this was test code.
>
> But it was not obvious to me exactly what was the test and what
> was context.

OK, next time I should be more clear,


>> That was the problem. When using:
>>      resultSet.getInt("Count");
>> instead of:
>>      resultSet.next();
>>
>> I get the error I expected.
>
> Calling a getXxxx before next should give an error even if
> statement was not closed.

That is what you would expect, but with SQLite it is not necessary.
But it would better to do it anyway. Even if it is throwaway code.


>> The real method is now:
>>      @Override
>>      public void close() throws SQLite3Exception {
>>          boolean closedResultSet = false;
>>
>>          try {
>>              Statement stmt = resultSet.getStatement();
>>
>>              resultSet.close();
>
> There mys be missing an assignment here.

The resultSet is assigned in the constructor of the class.


>
>>              stmt.close();
>>          } catch (SQLException e) {
>>              if (closedResultSet) {
>>                  throw new SQLite3Exception("Could not close Statement after closing ResultSet.");
>>              }
>>              throw new SQLite3Exception("Could not close ResultSet.");
>
> I don't like this conditional here.
>
> Either separate catch or just let the SQLException propagate information
> about what the problem was.

I want it to be clear when the closing of the resultSet went OK, but
the closing of stmt not. I was thinking about doing it in two tries,
but did not do it. And I should do three tries, because the fetching
of stmt can also go wrong. So now I have:
    @Override
    public void close() throws SQLException {
        Statement stmt;

        try {
            stmt = resultSet.getStatement();
        } catch (SQLException e) {
            SQLException extException = new SQLException("Could not get Statement from ResultSet.");

            extException.addSuppressed(e);
            e = extException;
            throw e;
        }
        resultSet.close();
        try {
            stmt.close();
        } catch (SQLException e) {
            SQLException extException = new SQLException("Could not close Statement after closing ResultSet.");

            extException.addSuppressed(e);
            e = extException;
            throw e;
        }
    }


>> The reason that I wrote this code was that I do not want to have to
>> put a Statement and a ResultSet into my try with resources.
>
> I think it is common to use one try for Statement and one
> for ResultSet.

I know, but I do not like that. And it also does not hurt to just
write something for the fun of it. :-D

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