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


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

Is this the way to work with try with resources

Started byCecil Westerhof <Cecil@decebal.nl>
First post2017-08-08 13:26 +0200
Last post2017-08-09 06:39 +0200
Articles 10 on this page of 30 — 5 participants

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


Contents

  Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-08 13:26 +0200
    Re: Is this the way to work with try with resources Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-08 12:51 +0000
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 07:10 +0200
    Re: Is this the way to work with try with resources Patrick Roemer <sangamon@netcologne.de> - 2017-08-08 18:29 +0200
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 07:20 +0200
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 07:16 +0200
    Re: Is this the way to work with try with resources Patrick Roemer <sangamon@netcologne.de> - 2017-08-08 19:30 +0200
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 06:49 +0200
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 07:01 +0200
      Re: Is this the way to work with try with resources Patrick Roemer <sangamon@netcologne.de> - 2017-08-09 15:39 +0200
    Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-08 21:25 -0400
      Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-08 21:36 -0400
        Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 07:29 +0200
          Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-09 20:53 -0400
            Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-09 23:03 -0400
      Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-08 21:48 -0400
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 07:24 +0200
    Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 06:26 +0200
      Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 08:30 +0200
      Re: Is this the way to work with try with resources Andreas Leitgeb <avl@logic.at> - 2017-08-09 09:40 +0000
        Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 12:56 +0200
          Re: Is this the way to work with try with resources Andreas Leitgeb <avl@logic.at> - 2017-08-09 16:51 +0000
            Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 19:37 +0200
              Re: Is this the way to work with try with resources Andreas Leitgeb <avl@logic.at> - 2017-08-09 19:51 +0000
                Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 22:20 +0200
                  Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 23:17 +0200
            Re: Is this the way to work with try with resources Patrick Roemer <sangamon@netcologne.de> - 2017-08-09 22:08 +0200
          Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-09 18:07 -0400
      Re: Is this the way to work with try with resources Arne Vajhøj <arne@vajhoej.dk> - 2017-08-09 18:05 -0400
    Re: Is this the way to work with try with resources Cecil Westerhof <Cecil@decebal.nl> - 2017-08-09 06:39 +0200

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


#37109

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-09 12:56 +0200
Message-ID<8760dxuhzl.fsf@munus.decebal.nl>
In reply to#37107
Andreas Leitgeb <avl@logic.at> writes:

> Cecil Westerhof <Cecil@decebal.nl> wrote:
>>     private static void statistics() {
>>         try (ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV);
>>              ResultSet rsUnused = executeQuery(COUNT_UNUSED_PROV);
>>              ResultSet rsUsed   = executeQuery(COUNT_USED_PROV)) {
>
> and
>
>>     private static ResultSet executeQuery(String query) throws SQLException {
>>         return conn.createStatement().executeQuery(query);
>>     }
>
> So, if one of the queries fails, what will happen to the statements 
> created so far?
>
> Or, rather, what will *not* happen to them?

If I interpreted try with resources correctly they are destroyed and
nothing is done with them. But that is not a problem in my opinion. It
should almost never happen. And I so not see a big win in that when
the third is going wrong, the first and second are displayed.
Also I think it is very unlikely that the first and second are
successful and only the third goes wrong.


>
>>             format = String.format("There are %%,%dd %%-6s proverbs.%%n",
>>                                    String.format("%,d", count).length());
>>             System.out.printf(format, count, "total");
>
> What's the point of determining the length of e.g. "1,234,567" just to
> set it as the length for a "%,d", which would obviously produce exactly
> that length, anyway?

Because I use it for the second and third.

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

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


#37112

FromAndreas Leitgeb <avl@logic.at>
Date2017-08-09 16:51 +0000
Message-ID<slrnoomfkk.o2q.avl@logic.at>
In reply to#37109
Cecil Westerhof <Cecil@decebal.nl> wrote:
> Andreas Leitgeb <avl@logic.at> writes:
>> Cecil Westerhof <Cecil@decebal.nl> wrote:
>>>     private static void statistics() {
>>>         try (ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV);
>>>              ResultSet rsUnused = executeQuery(COUNT_UNUSED_PROV);
>>>              ResultSet rsUsed   = executeQuery(COUNT_USED_PROV)) {
>> and
>>>     private static ResultSet executeQuery(String query) throws SQLException {
>>>         return conn.createStatement().executeQuery(query);
>>>     }
>> So, if one of the queries fails, what will happen to the statements 
>> created so far?
>> Or, rather, what will *not* happen to them?
> If I interpreted try with resources correctly they are destroyed and
> nothing is done with them.

This claim is self-contradictory. They cannot be both, "destroyed" and
"nothing done with them" at the same time.

Anyway, I think, we're conflating two aspects here:
  1.) your app is a simple client tool, which wouldn't really need any
     error-handling with explicit cleanup at all. It could just System.exit()
     for any exception, and all cleanup will be cared for.
  2.) The discussion on how to do try-with-ressources *correctly*.

I'd prefer to stick with "2.)" and ignore the fact that your specific
task doesn't really demand correctness. Ok? (Otherwise there's no point
in participating in the discussion any longer.)

Now, in that snippet above, it would (3 times) create a statement, then execute 
a query to get a resultset.  If one of the queries went wrong, then the
try would auto-close any previously obtained resultsets, but it would not
do anything on the statements - in particular: not clean them up.

So, if instead it were a long running server app, it would leak up to
three statements each time your proc is run, until it eventually 
closes and reopens the connection.

>>>             format = String.format("There are %%,%dd %%-6s proverbs.%%n",
>>>                                    String.format("%,d", count).length());
>>>             System.out.printf(format, count, "total");
>> What's the point of determining the length of e.g. "1,234,567" just to
>> set it as the length for a "%,d", which would obviously produce exactly
>> that length, anyway?
> Because I use it for the second and third.

Ah, first row is always the widest value? Ok, that's a justification.

But even then I'd probably have used:
 int maxLen = String.format("%,d", count).length(); // first count is largest
 format = "There are %," + maxLen + "d %-6s proverbs.%n";
for slightly better readability.

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


#37113

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-09 19:37 +0200
Message-ID<87y3qstzey.fsf@munus.decebal.nl>
In reply to#37112
Andreas Leitgeb <avl@logic.at> writes:

> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> Andreas Leitgeb <avl@logic.at> writes:
>>> Cecil Westerhof <Cecil@decebal.nl> wrote:
>>>>     private static void statistics() {
>>>>         try (ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV);
>>>>              ResultSet rsUnused = executeQuery(COUNT_UNUSED_PROV);
>>>>              ResultSet rsUsed   = executeQuery(COUNT_USED_PROV)) {
>>> and
>>>>     private static ResultSet executeQuery(String query) throws SQLException {
>>>>         return conn.createStatement().executeQuery(query);
>>>>     }
>>> So, if one of the queries fails, what will happen to the statements 
>>> created so far?
>>> Or, rather, what will *not* happen to them?
>> If I interpreted try with resources correctly they are destroyed and
>> nothing is done with them.
>
> This claim is self-contradictory. They cannot be both, "destroyed" and
> "nothing done with them" at the same time.

Sadly communication is not my strong suit. I mend: they are not used
to retrieve values and are destroyed. The latter is not true I
understand from your explanation.


> Anyway, I think, we're conflating two aspects here:
>   1.) your app is a simple client tool, which wouldn't really need any
>      error-handling with explicit cleanup at all. It could just System.exit()
>      for any exception, and all cleanup will be cared for.
>   2.) The discussion on how to do try-with-ressources *correctly*.

At the moment 1 is the case, but I also want to do 2: as the twig is
bent the tree is inclined.


> I'd prefer to stick with "2.)" and ignore the fact that your specific
> task doesn't really demand correctness. Ok? (Otherwise there's no point
> in participating in the discussion any longer.)

OK. :-D


> Now, in that snippet above, it would (3 times) create a statement, then execute 
> a query to get a resultset.  If one of the queries went wrong, then the
> try would auto-close any previously obtained resultsets, but it would not
> do anything on the statements - in particular: not clean them up.
>
> So, if instead it were a long running server app, it would leak up to
> three statements each time your proc is run, until it eventually 
> closes and reopens the connection.

Luckily I created a class SQLite3 and changed all my:
    ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV)
to:
    ResultSet rsTotal  = sqlite3Conn.executeQuery(COUNT_TOTAL_PROV)

Where sqlite3Conn is an instance of SQLite3.

I had there the following function:
    public ResultSet executeQuery(String query) throws SQLException {
        return conn.createStatement().executeQuery(query);
    }
but I now changed that to:
    public ResultSet executeQuery(String query) throws SQLException {
        try (Statement stmt = conn.createStatement()) {
            return stmt.executeQuery(query);
        }
    }

This should take care of the leakage.


By the way is there a way to ‘find’ all open Statements? That could be
used to verify if a long running application is leaking resources.


>>>>             format = String.format("There are %%,%dd %%-6s proverbs.%%n",
>>>>                                    String.format("%,d", count).length());
>>>>             System.out.printf(format, count, "total");
>>> What's the point of determining the length of e.g. "1,234,567" just to
>>> set it as the length for a "%,d", which would obviously produce exactly
>>> that length, anyway?
>> Because I use it for the second and third.
>
> Ah, first row is always the widest value? Ok, that's a
> justification.

Yep, total = used + notUsed. So both cannot be longer as total.


> But even then I'd probably have used:
>  int maxLen = String.format("%,d", count).length(); // first count is largest
>  format = "There are %," + maxLen + "d %-6s proverbs.%n";
> for slightly better readability.

You are right: I implemented it.


Thanks for the clarification and the readability.

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

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


#37114

FromAndreas Leitgeb <avl@logic.at>
Date2017-08-09 19:51 +0000
Message-ID<slrnoomq5s.o2q.avl@logic.at>
In reply to#37113
Cecil Westerhof <Cecil@decebal.nl> wrote:
> I had there the following function:
>     public ResultSet executeQuery(String query) throws SQLException {
>         return conn.createStatement().executeQuery(query);
>     }
> but I now changed that to:
>     public ResultSet executeQuery(String query) throws SQLException {
>         try (Statement stmt = conn.createStatement()) {
>             return stmt.executeQuery(query);
>         }
>     }
> This should take care of the leakage.

I fear, next trouble is right ahead.

try doesn't only close it's resource on failure, but also on completion!

That means, it will (because closing the statement will also close the
ResultSet) return an already closed ResultSet.


> By the way is there a way to ‘find’ all open Statements? That could be
> used to verify if a long running application is leaking resources.

I don't know, but I don't see any good usecase for it.
Any piece of code ought to know only about its own Statements.
Once you close the connection, you don't need to care about
any left-overs, anyway, and before you close the connection, 
any of the existing Statements might be actively used in other
parts/threads of the code.


I think, after all is said and done, your code may look like this:
  try (
     Statement stmnt1 = conn.createStatement();
     ResultSet rs1 = stmnt1.executeQuery(...);
     Statement stmnt2 = conn.createStatement();
     ResultSet rs2 = stmnt1.executeQuery(...);
     Statement stmnt3 = conn.createStatement();
     ResultSet rs3 = stmnt1.executeQuery(...);
  ) {
      // use *ALL the RS's*!
  }
(except for more expressive variable names ;-) )

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


#37116

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-09 22:20 +0200
Message-ID<87tw1gtrw3.fsf@munus.decebal.nl>
In reply to#37114
Andreas Leitgeb <avl@logic.at> writes:

> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> I had there the following function:
>>     public ResultSet executeQuery(String query) throws SQLException {
>>         return conn.createStatement().executeQuery(query);
>>     }
>> but I now changed that to:
>>     public ResultSet executeQuery(String query) throws SQLException {
>>         try (Statement stmt = conn.createStatement()) {
>>             return stmt.executeQuery(query);
>>         }
>>     }
>> This should take care of the leakage.
>
> I fear, next trouble is right ahead.
>
> try doesn't only close it's resource on failure, but also on completion!
>
> That means, it will (because closing the statement will also close the
> ResultSet) return an already closed ResultSet.

I have in my code:
    private static void displayOldestUsed() {
        try (ResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
            if (rsOldest.next()) {
                giveMessage("Oldest used: " + rsOldest.getString("used") + ".");
            }
        } catch (SQLException e) {
            giveError("Error in displayOldestUsed");
            e.printStackTrace();
            fatalError("");
        }
    }

And rsOldest.getString("used") gives the result I would expect. Or am
I just ‘lucky’?

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

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


#37117

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-09 23:17 +0200
Message-ID<87mv78tp9k.fsf@munus.decebal.nl>
In reply to#37116
Cecil Westerhof <Cecil@decebal.nl> writes:

> Andreas Leitgeb <avl@logic.at> writes:
>
>> Cecil Westerhof <Cecil@decebal.nl> wrote:
>>> I had there the following function:
>>>     public ResultSet executeQuery(String query) throws SQLException {
>>>         return conn.createStatement().executeQuery(query);
>>>     }
>>> but I now changed that to:
>>>     public ResultSet executeQuery(String query) throws SQLException {
>>>         try (Statement stmt = conn.createStatement()) {
>>>             return stmt.executeQuery(query);
>>>         }
>>>     }
>>> This should take care of the leakage.
>>
>> I fear, next trouble is right ahead.
>>
>> try doesn't only close it's resource on failure, but also on completion!
>>
>> That means, it will (because closing the statement will also close the
>> ResultSet) return an already closed ResultSet.
>
> I have in my code:
>     private static void displayOldestUsed() {
>         try (ResultSet rsOldest = sqlite3Conn.executeQuery(OLDEST_USED)) {
>             if (rsOldest.next()) {
>                 giveMessage("Oldest used: " + rsOldest.getString("used") + ".");
>             }
>         } catch (SQLException e) {
>             giveError("Error in displayOldestUsed");
>             e.printStackTrace();
>             fatalError("");
>         }
>     }
>
> And rsOldest.getString("used") gives the result I would expect. Or am
> I just ‘lucky’?

Nope, I did something wrong. When doing it right I got:
    java.sql.SQLException: ResultSet closed

So I know do it with Statement and ResultSet in the try with
resources. Makes my SQLite3 class a bit less useful.

But my statistics is now:
    private static void statistics() {
        try  {
            int    count;
            String format;
            int    maxLen;

            count  = sqlite3Conn.getCount(COUNT_TOTAL_PROV);
            // First count is the largest
            maxLen = String.format("%,d", count).length();
            format = "There are %," + maxLen + "d %-6s proverbs.";
            giveMessage(String.format(format, count, "total"));
            count  = sqlite3Conn.getCount(COUNT_UNUSED_PROV);
            if (count != 0) {
                giveMessage(String.format(format, count, "unused"));
            }
            count  = sqlite3Conn.getCount(COUNT_USED_PROV);
            giveMessage(String.format(format, count, "used"));
        } catch (SQLException e) {
            giveError("Error in statistics");
            e.printStackTrace();
            fatalError("");
        }
    }

Because I defined:
    public int getCount(String query) throws SQLException {
        int count;

        try (Statement stmt     = createStatement();
            ResultSet  rsCount  = stmt.executeQuery(query)) {
            count = rsCount.getInt("count");
        }
        return count;
    }

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

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


#37115

FromPatrick Roemer <sangamon@netcologne.de>
Date2017-08-09 22:08 +0200
Message-ID<omfq30$t9$1@newsreader4.netcologne.de>
In reply to#37112
Responding to Andreas Leitgeb:
> Cecil Westerhof <Cecil@decebal.nl> wrote:
>> Andreas Leitgeb <avl@logic.at> writes:
>>> Cecil Westerhof <Cecil@decebal.nl> wrote:
>>>>     private static void statistics() {
>>>>         try (ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV);
>>>>              ResultSet rsUnused = executeQuery(COUNT_UNUSED_PROV);
>>>>              ResultSet rsUsed   = executeQuery(COUNT_USED_PROV)) {
>>> and
>>>>     private static ResultSet executeQuery(String query) throws SQLException {
>>>>         return conn.createStatement().executeQuery(query);
>>>>     }
[...]
> Now, in that snippet above, it would (3 times) create a statement, then execute 
> a query to get a resultset.  If one of the queries went wrong, then the
> try would auto-close any previously obtained resultsets, but it would not
> do anything on the statements - in particular: not clean them up.

The statements won't be closed, no matter whether the queries succeed or
fail. The try-with-resources will only take care of closing the result
sets. (And it will do so independent of any exceptions triggered in the
process.)

Best regards,
Patrick

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


#37120

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-09 18:07 -0400
Message-ID<omg13o$1r4b$2@gioia.aioe.org>
In reply to#37109
On 8/9/2017 6:56 AM, Cecil Westerhof wrote:
> Andreas Leitgeb <avl@logic.at> writes:
> 
>> Cecil Westerhof <Cecil@decebal.nl> wrote:
>>>      private static void statistics() {
>>>          try (ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV);
>>>               ResultSet rsUnused = executeQuery(COUNT_UNUSED_PROV);
>>>               ResultSet rsUsed   = executeQuery(COUNT_USED_PROV)) {
>>
>> and
>>
>>>      private static ResultSet executeQuery(String query) throws SQLException {
>>>          return conn.createStatement().executeQuery(query);
>>>      }
>>
>> So, if one of the queries fails, what will happen to the statements
>> created so far?
>>
>> Or, rather, what will *not* happen to them?
> 
> If I interpreted try with resources correctly they are destroyed

Nope.

The try statement only works with the variable(s) in the try statement.
Not with temporary variable created deep down in some calls.

Arne

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


#37119

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-08-09 18:05 -0400
Message-ID<omg0vf$1r4b$1@gioia.aioe.org>
In reply to#37095
On 8/9/2017 12:26 AM, Cecil Westerhof wrote:
> Cecil Westerhof <Cecil@decebal.nl> writes:
>> I thought that I could rewrite it to:
>>      private static void statistics() {
>>          try (Statement stmt     = conn.createStatement();
>>               ResultSet rsTotal  = stmt.executeQuery(COUNT_TOTAL_PROV);
>>               ResultSet rsUnused = stmt.executeQuery(COUNT_UNUSED_PROV);
>>               ResultSet rsUsed   = stmt.executeQuery(COUNT_USED_PROV)) {

> I do not know enough about the JDBC. When looking at:
>      https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html
> 
> It clearly states that you normally only can have one current
> result-set pro statement. It says there:
>      All execution methods in the Statement interface implicitly close
>      a current ResultSet object of the statement if an open one exists.
> 
> But that is clearly not true, because the other ones still work, but
> are replaced with the other one.

You can somewhat expects drivers to work properly in normal
scenarios, but in more exotic scenarios there can be bugs.

> The solution is to have a statement pro result-set, but than this
> statement is only necessary for getting the result-set. So I rewrote
> statistics to:
>      private static void statistics() {
>          try (ResultSet rsTotal  = executeQuery(COUNT_TOTAL_PROV);
>               ResultSet rsUnused = executeQuery(COUNT_UNUSED_PROV);
>               ResultSet rsUsed   = executeQuery(COUNT_USED_PROV)) {

> And wrote the function executeQuery to make the code a little more
> compact:
>      private static ResultSet executeQuery(String query) throws SQLException {
>          return conn.createStatement().executeQuery(query);
>      }
> 

Still bad. Maybe even worse.

It is not in general safe to non-serial execute multiple
SELECT's on a single connection.

You do not get the statement objects closed. The temporary
objects in the convenience method does not get handled by
the try statement.

Arne

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


#37096

FromCecil Westerhof <Cecil@decebal.nl>
Date2017-08-09 06:39 +0200
Message-ID<87efslwe0h.fsf@munus.decebal.nl>
In reply to#37077
ram@zedat.fu-berlin.de (Stefan Ram) writes:

> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>private static void printUnused
>>( final java.sql.Statement statement,
>>  final java.lang.String format,
>>  final int count ) 
>
>   For those who think that now there are too many
>   parameters, here's a parameterless version:
>
> private static java.sql.Statement statement;
> private static int count;
> private static java.lang.String format;
>
> private static void printTotal() 
> { System.out.printf( format, count, "total" );  }
>
> private static void printUnused() 
> throws java.sql.SQLException
> { try( final java.sql.ResultSet rsUnused = statement.executeQuery( COUNT_UNUSED_PROV )) 
>   { final int countUnused = rsUnused.getInt( "no" );
>     if( countUnused != 0 )java.lang.System.out.printf( format, count, "unused" ); }}
>
> private static void printUsed() 
> throws java.sql.SQLException
> { try( final java.sql.ResultSet rsUsed = statement.executeQuery( COUNT_USED_PROV )) 
>   { final int countUsed = rsUsed.getInt( "no" );
>     java.lang.System.out.printf( format, countUsed, "used" ); }}
>
> private static void printThreeStatistics() 
> throws java.sql.SQLException
> { printTotal();
>   printUnused();
>   printUsed(); }
>
> private static void makeFormat()
> throws java.sql.SQLException
> { final java.lang.String format = java.lang.String.format
>   ( "There are %%,%dd %%6s proverbs.%%n", java.lang.String.format( "%,d", count ).length() );
>   printThreeStatistics(); }
>
> private static void makeCount() 
> throws java.sql.SQLException
> { try( final java.sql.ResultSet rsTotal = statement.executeQuery( COUNT_TOTAL_PROV )) 
>   { count = rsTotal.getInt( "no" );
>     makeFormat(); }}
>
> private static void makeStatement() 
> { try( final java.sql.Statement s = conn.createStatement() ) 
>   { statement = s; makeCount(); }
>   catch( final java.sql.SQLException exception ) 
>   { java.lang.System.err.println( "Error in statistics" );
>     exception.printStackTrace();
>     fatalError( "" ); }}
>
> private static void printStatistics() 
> { makeStatement(); }

To be honest I find that also a bit long-winded. I found a way to do
it with one try statement. See my reply on my own post.

The problem was that a Statement can only have one ResultSet. I should
study the JDBC api.

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

[toc] | [prev] | [standalone]


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

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


csiph-web