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: Sun, 13 Aug 2017 15:27:54 +0200
Organization: Decebal Computing
Lines: 42
Message-ID: <8760drwqat.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> <slrnootj2q.o2q.avl@logic.at> <87bmnlyrx7.fsf@munus.decebal.nl> <omnqgg$75d$1@dont-email.me> <87h8xcxvux.fsf@munus.decebal.nl> <ompdfp$4mm$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org; posting-host="1615173a1409002a85fbdd25ac4b9ead"; logging-data="28699"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19XTaaAu/boBZTVapNDp1OqvlrhSPxsJSg="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
X-Homepage: http://www.decebal.nl/
Cancel-Lock: sha1:MfPtFj7cemFlvH9fPR0qd+iNqDA= sha1:dcDCthfSsLIX8xqjZcevVRBTxwE=
Xref: csiph.com comp.lang.java.programmer: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