Frank Sommers
Posts: 2642
Nickname: fsommers
Registered: Jan, 2002
|
|
Re: The Trouble with Checked Exceptions
|
Posted: Aug 30, 2003 12:15 AM
|
|
> All the database calls can result in a SQLException which
> are checked exceptions. At production time, this code
> should only fail if the database connection is lost or the
> database crashes.
Not really. The code can also fail if someone, unbeknown to your application, changes the database schema so that the specified relations and fields no longer exist. Of course, the question is, does it help us to know what went wrong when accessing the database? In the case of this simple query, it might not matter whether the DBMS was down, or a table changed. So, in this simple example, it might not matter whether SQLException is a checked exception.
> So the problem with checked exceptions is that it forces
> the library user to handle the exception even if this
> isn't required.
But it is required. The app should handle this exception. For instance, it might fail over to a backup database, etc. If a developer has to expect this exception (because it's declared by the JDBC API), that gives the programmer another chance to think and consider what remedies can be applied when the exception does happen.
> In the above code, we should not be
> catching exceptions from the query execution and result
> set retrieval since exceptions from these calls will most
> likely be from a coding error.
Or, again, a change in the system (ie. schema change). But in the case of an update, there can be a whole set of other reasons for SQLException to occur (ie. attempts to violate primary key constraints, incorrect data types, etc). Which brings us to....
>Note however, part of this
> problem is due to lack of exception hierarchy for SQL
> exceptions.
Which is why I think typed exceptions should be added to SQL. Currently, each DBMS generates its own error codes when SQL errors occur. For instance, if I try to do an insert with values that would violate primary key constraints, the DBMS might generate some error code. That code, in turn, bubbles up as an SQL Exception. What I'd really like to see is for the SQL language to have a typed exception hierarchy. For instance, it might throw a "IntegrityViolationException, " etc. Having these typed exceptions generated as part of SQL statements would really help database application development.
For instance, suppose you wanted to insert a customer record into a database table with a primary key of a customer's social security number. Currently, I'd have to write code such as:
try {
PreparedStatement st =
dbconnection.prepareStatement("select ssn from customer where ssn=?");
st.setString(1, customer.getSSN());
ResultSet rs = st.executeQuery();
if (rs.next()) {
//customer is already in DB,
//inserting would cause an SQLException
//just close db objects and return
} else {
//do the insert
st = dbConnection.prepareStatement("insert into customer ....")';
dbConnection.commit();
}
} catch (SQLException e) {
////
}
This is really bad code. I need to check first if the customer is already in the database - if I try to the insert and the customer is already in the database, I get an SQLException. But I can't tell whether the SQLException occurred because the DBMS went down, or because if the attempted integrity violation. So not having typed SQL exceptions renders SQLException itself more or less useless. What I'd like to see, instead, is something like:
try {
PreparedStatement st =
dbConnection.prepareStatement("insert into customer .....");
st.executeUpdate();
dbConnection.commit();
} catch (SQLIntegrityException e) {
///this is OK - the customer is already there, so do nothing
} catch (SQLConnectionException e) {
//this is not OK - fail over, or do some other recovery work here
}
But those different DBMS exceptions must originate from the database, as a result of the SQL statements. That can only happen if there is a standard hierachy of SQL exceptions defined by SQL itself.
|
|
Previous Topic
