On Mon, Sep 01, 2003 at 07:03:33PM -0700, joe user wrote:
>
> --- Oliver Jowett <oliver@opencloud.com> wrote:
> > Do the close() in a finally block. It's good
> > practice anyway.
>
> That's a good idea, but unfortunately
> Connection.close() throws SQLException, so I would
> have to do something like this:
>
> try { }
> catch { }
> finally {
> try { db.close(); }
> catch(SQLException e) { log(...); }
> }
Yes. Note that real code is likely to be doing a decent amount of work in
the try block (directly or indirectly), so the added complexity of the
finally block isn't usually an issue.
The other way of doing it, which has slightly different error-handling
behaviour, is:
try {
try {
// ...
} finally {
db.close();
}
} catch (SQLException e) {
// ...
}
but that can be just as hard to read, depending on the exact code.
> This works... but isn't Java/JDBC supposed to make our
> lives easier, and focus on the problem we're solving
> instead of putting in extra hard-to-read boilerplate
> code (a try/catch nested inside a finally block)?
As I see it, JDBC is more about providing a standardized API to many
database implementations, that can then be used to build higher-level tools.
As it's more of a system-level thing it does make sense to explicitly report
everything that goes wrong, as different applications may need different
error-handling policies. Think "system library" not "application framework".
> I think I'm going to convert everything to JDO so the
> JDO implementor can handle ALL of this stuff.
More generally, you want an adaption layer that presents an API that is
useful to your application and hides the JDBC details that are irrelevant or
can be dealt with in a standardized way. This is a flexibility-vs-convenience
design tradeoff.
-O