Jonathan Bruce's Blog

Exception chaining in JDBC

By defining a group of methods that allow a Throwable instance to be set at the SQLException level, this allow related exceptions definition introduced in JDBC RowSets to also provide chaining support. Overloading the current set of constructors should achieve chaining functionality and compliment the four other currently defined constructors.

public SQLException(Throwable cause);

public SQLException(String reason, Throwable cause);

public SQLException(String reason, String sqlState, Throwable cause);

I guess I am writing with my Specification Lead hat on here, but I also want to be sure we correctly gauge the needs of the community, so I encourage you all to add your comments below. Over the next few weeks I also intend to write about how JDBC 4.0 is progressing and gauge the communities position as we progress through the Java Community Process.

Comments

• Subclasses would be welcome
  Subclasses of SQLException would be very welcome. Especially useful would be an exception indicating the connection is no longer open/valid ( ConnectionClosedException, for instance) and that the syntax of the SQL query was invalid (QuerySyntaxException). The JDBC driver vendor would, of course, be responsible for throwing the appropriate subclass.

  This would make programs easier to debug, problems easier to report, and servers more robust.

  Posted by: jimothy on June 15, 2004 at 10:06 AM

• It would be great
  No more RDBMS propietary error code deciphering!!

  Posted by: nicolasdijkstra on June 15, 2004 at 12:20 PM

• absolutely
  Sometimes a stack trace is all you have to go by when diagnosing errors "in the field". So having access to the error messages at each level of the stack trace would be a boon.

  For example, a generic "connection error" message would be that much more useful if you could see the underlying error message of "connection refused on port 1521".

  Posted by: mikeburke on June 16, 2004 at 03:17 AM

• Please!
  The expert group was thinking of not adding exception chaining? That's one of the most useful things in JSDK 1.4. I've had to define my own subclass of given throwables to get developers to do exception chaining, which is overkill. Adding the appropriate constructors to SQLException is harmless and much more likely to be used.

  We need it in SQLException (and pretty much every other exception defined in J2EE).

  Thanks,

  Dave

  Posted by: dwalend on June 16, 2004 at 06:06 AM

• Throwable.initCause
  It will be good to overload the SQLException constructors to take the 'cause'. However, even without doing so, it is achievable by simply doing,
  thesqlexception.initCause(thecause);
  throw thesqlexception;

  This is possible since jdk1.4. Only the driver implementers need to make sure to always do proper initCause before throwing the SQLException.
  

  Posted by: sutanu on June 16, 2004 at 06:44 AM

• SQLException subclass suggestions
  Greetings,

  The two most important sql-related states that come to my mind are foreign key and unique constraint violations. Detecting these two conditions with exception codes among multiple relational databases has always been a pet peeve (not that business logic should rely on these states, it's just nice to be able to handle these situtations accordingly).

  Posted by: boytoy on June 16, 2004 at 08:22 AM

• Subclasses would be welcome
  There are a good handful of situations I want to be able to distinguish between:

  1. Couldn't connect to database because it could not be found (preferably distinguishing between finding the database and finding the machine - nice but not essential).

  2. Couldn't connect to database because authentication failed.

  3. Couldn't run SQL because it's invalidly formed.

  4. Couldn't run SQL because it would cause an integrity constraint violation.

  Posted by: archangel on June 17, 2004 at 01:29 AM

• Subclasses would be welcome
  Right! The point is, let the database (or driver) vendor decide what type of error occurred (and what type of exception to throw), because it is, after all, the vendor who "knows" this.

  Imagine if, for instance, my database application could catch a java.sql.AuthenticationException and instruct the user to check his or her username and password instead of generically stating, "A database error occurred" followed by the often cryptic, always user unfriendly database error message (or try and parse the proprietary DB error message and codes to determine what went wrong). That's precisely why it pays to Be Specific with your exceptions.

  Posted by: jimothy on June 17, 2004 at 08:21 AM

• Please!
  Aren't you more likely to do the opposite, that is, wrap another exception around a SQLException than wrap an SQLException around another exception? The only instance I can think of when the latter my be useful is chaining an IOException to an SQLException when a network-related error occurs. And that's up to the driver vendor to implement, so if they need to call initCause(), I don't see that as cause for concern.

  Actually, I'm curious why anyone other than JDBC driver vendors would ever need to throw an SQLException.

  My vote (for all that its worth): Don't do it. At best, its unnecessary. At worst, it'll encourage developers to throw SQLException wrapping business exceptions when they should be doing the opposite.

  Posted by: jimothy on June 17, 2004 at 08:40 AM

• Please!
  I always wondered why this didn't make in to v1.4 when chained exception support was added. As has been pointed out you can work around it using initCause() but this is a pain. Someone questioned the usefulness of this. I like to use it when performing multiple database queries/updates in a transaction. When doing this I create a new SQLException with a message basically telling which update failed and then chain in the SQLException that called it like so:

  throw (SQLException)new SQLException("Error updating blah").initCause(sqlex);

  Note the ugly case...

  Posted by: yeroc on June 18, 2004 at 11:47 AM

• overloading the exception constructor
  My only concern for overloading constructors of exception classes with Throwable is that it tends to clutter the class. You will need to add one new constructor with Throwable included for almost every existing constructor.
  And then we have to overload constructors of other exception classes as well ? It all gets cumbersome very soon.
  

  Posted by: sutanu on June 18, 2004 at 02:17 PM

This work is licensed under a Creative Commons License.