Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Not closing a SQL(ite3) connection Date: Sun, 13 Aug 2017 11:34:18 -0000 (UTC) Organization: A noiseless patient Spider Lines: 60 Message-ID: References: <87a839um2q.fsf@munus.decebal.nl> <874lte1pdj.fsf@munus.decebal.nl> <87bmnlyrx7.fsf@munus.decebal.nl> <87h8xcxvux.fsf@munus.decebal.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sun, 13 Aug 2017 11:34:18 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="70f7f9b9062e6e503a07259b35ef79a7"; logging-data="4822"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/Zzd7p0GrnE7RLoT4sp955eT809/DwFBo=" User-Agent: Pan/0.141 (Tarzan's Death; 168b179 git.gnome.org/pan2) Cancel-Lock: sha1:OxFqbyli1NXFYPVUZMyzhsmWZiM= Xref: csiph.com comp.lang.java.programmer:37175 On Sun, 13 Aug 2017 00:30:14 +0200, Cecil Westerhof wrote: > Martin Gregorie 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 |