标签云

微信群

扫码加入我们

WeChat QR Code

What is considered best practices when cleaning up JDBC resources and why? I kept the example short, thus just the cleaning up of the ResultSet. finally{if(rs != null)try{ rs.close(); } catch(SQLException ignored) {}}versusfinally{try{ rs.close(); } catch(Exception ignored) {}}Personally I favour the second option since it is a bit shorter. Any input on this is much appreciated.


Never tought about the second option - it can be useful for closing streams as well. BTW - I like your name for the ignored exception and will keep that in mind :-)

2019年04月19日24分05秒

Empty catch-blocks??

2019年04月20日24分05秒

Anyway, forget about "keeping the example short" :-)

2019年04月20日24分05秒

I would recommend Vickie's reply below.It is never really good practice to expect an exception to be thrown as part of the normal flow of code.In your second, preferred block, you're relying on the exception to handle the case of a null ResultSet instead of checking it yourself.

2019年04月20日24分05秒

Of course you can hide this with the Execute Around idiom. Or use an ORM.

2019年04月19日24分05秒

Tom: True. I rather like Spring's JdbcTemplate for this type of stuff. Although, truth be told, I actually like the syntax in my answer (I claim "it's not the prettiest" based on opinions I have heard from others). I find it beautiful in its simplicity and structure. Strange, but true.

2019年04月19日24分05秒

How do you handle SQLExceptions thrown by close() methods?

2019年04月19日24分05秒

André: I purposely don't handle those SQLExceptions because I prefer to know if the driver is experiencing trouble. It's a matter of personal preference.

2019年04月20日24分05秒

+1 for not doing something stupid with nulls. -1 for your exception handling, and for appearing a bit confused as to how three locals will have been initialised.

2019年04月19日24分05秒

Tom - this is just an assessment of the consequences implied by the OPs suggestion (version 2). Thought it would be clear enough...

2019年04月19日24分05秒

Even if it were okay to overlook such crimes, you have coalesced finally blocks. finally blocks do not coaslesce.

2019年04月20日24分05秒

that's exactly how I do it. I don't do any logging in the 'finally' catch blocks. I tend to add the logging in the catch blocks just before the finally block.

2019年04月20日24分05秒

Oh dear. Something daft with nulls and swallowing exceptions.

2019年04月19日24分05秒

logging != swallowing

2019年04月19日24分05秒

This is brilliant solution as Tom stated thats a check for null is cheaper than throwing a NullPointerException. Logging is optional in my opinion, especially by a close. Who cares if it fails to close,if it was no successful then odds are your pooling is not going to reuse the connection anyway etc.

2019年04月20日24分05秒

What happens if your ResultSet initialization returns an error (in case of a misconfigured or unresponsive database)?

2019年04月20日24分05秒

Jean what should happen? It doesn't need to be closed in that case.

2019年04月20日24分05秒

+1 for not doing something stupid with nulls. -1 for your exception handling.

2019年04月19日24分05秒

Tom it is not my exception handling :) The post just avoids treating NPE and SQLExceptions in the same way.

2019年04月19日24分05秒

What does this answer have to do with the question? If using database connection pooling, it becomes even more important to be sure you close all the resources (statements and result sets) created by the current connection so you don't put a dirty connection back into the pool.

2019年04月20日24分05秒

fair point about DBCP - you do still need to clean up. But combine it with the Spring framework (using the JDBCTemplate) and you can remove a lot of boiler plate code.

2019年04月20日24分05秒

+1, but I would add logging for the catches

2019年04月19日24分05秒

you can use Logger before closing each. I assume you know this but one more time download.oracle.com/javase/1.4.2/docs/api/java/util/logging/…

2019年04月19日24分05秒

-1 Worst yet. null silliness. Swallowing exceptions. And a lack of finally.

2019年04月20日24分05秒

Item 7: Avoid Finalizers (Effective Java)

2019年04月19日24分05秒

books.google.com/…

2019年04月19日24分05秒