The general approach is - cleanup stuff is done in finally block:
Now, again, this is general practice, that if SQLException is thrown during cleanup, most of the time, the error is logged and code proceeds further - i.e. it is not treated as fatal (or fatal enough to end program's operation).
The reason is - we've go exception during closing of resource, right? So, if we are not able to close a resource properly, it won't affect program severely. Again, in real life program, connection pool is used - which is opened during application startup and closed during application's ending - where it won't do much harm if in rare case there's any problem during cleanup.
However, if the behavior is consistent (i.e. we are always getting such exceptions during closing of resources), then it needs further investigation.
I'm not expert in this area, but these are just my two cents.
I hope this helps.
Can the program continue upon failure? If not, then it's a fatal error. If it can continue, what are the ramifications of the error? Is it "Oh, that failed, please try again." or is it "Well, it would have been nice if that succeeded, but no matter."? Or something else?
That said: close failures are rare and usually mean that something's gone awry with the network.
One problem with SQLExceptions is that it's deucedly hard to figure out what caused them. Most DB's are really bad about reporting errors. If there are some details, it's usually some passive-aggressive error like "a column had bad data". Makes you want to reach through the wire and throttle the DB "Which freaking column?".
Dennis Putnam wrote:Thanks again. To me the only thing that makes sense is the last. I can't think of any reason why a close failure would do anything bad enough to prevent the app from running (does it prevent future connections or future uses of NEW statements?). That is the crux of my question. What possible harm, under any circumstance, would ignoring a close failure cause?
Well, there are implications of that.
Consider a worst case scenario - where you are getting this exception, and you are not able to close DB connection.
Now, when a connection is opened, and you get such exception during closing a connection, its fine from your perspective - because the moment you get out of that method, Connection object is eligible for gc.
But what about actual connection which is opened at DB side? When Connection object is garbage collected, it is very much possible that actual DB connection is still open.
Now, consider such problem from few hundred, or thousand clients (i.e. application is directly connecting to DB and application is being used by thousands of users).
Of course, it is quite hypothetical and/or worst case, but my point is - like Bear said, those exceptions during cleanup are not totally ignorable.
Edit: Oops! Bear replied before me
Dennis Putnam wrote:But would not the next connection attempt fail? In that case it would be caught by the exception on the connection attempt. That, I do always consider a fatal error.
Yes. As Bear said,
Bear Bibeault wrote:what happens if the DB runs out of connections because they weren't properly closed?
And it is indeed fatal.
The thing is, attempting to reason about unpredictable beasts like networks isn't the same as attempting to reason about Java code. You can rarely say "Event X happened here, so event Y must happen next". All you can do is to assume that bad things can happen at any time without warning.
But anyway I think if you asked people with large-scale database systems, they would say either that they have never had an occasion where closing a JDBC component threw an exception, or that they don't know because they don't bother to monitor for that particular situation.