How Do You Handle JDBC Errors/Exceptions? JDBC

In JDBC, errors and exceptions are identified by the java.sql.SQLException class (which extends the java.lang.Exception class).

SQLException is a checked exception. There are two types of exceptions in Java: checked and unchecked, or runtime, exceptions. A checked exception is a subclass of java.lang.Throwable (the Throwable class is the superclass of all errors and exceptions in the Java language) but not of RunTimeException (RuntimeException is the superclass of those exceptions that can be thrown during the normal operation of the Java VM). Checked exceptions have to be caught (and handled properly) or appear in a method that specifies in its signature that it throws that kind of exception. When a JDBC object (such as Connection, Statement, or ResultSet) encounters a serious error, it throws a SQLException. For example, an invalid database URL, an invalid database username or password, database connection errors, malformed SQL statements, an attempt to access a nonexistent table or view, and insufficient database privileges all throw SQLException objects. The client(the database application program) accessing a database server needs to be aware of any errors returned from the server. JDBC give access to such information by providing several levels of error conditions:

• SQLException: SQLExceptions are Java exceptions that, if not handled, will terminate the client application. SQLException is an exception that provides information on a database access error or other errors.
• SQLWarning: SQLWarnings are subclasses of SQLException, but they represent nonfatal errors or unexpected conditions, and as such, can be ignored. SQLWarning is an exception that provides information on database access warnings. Warnings are silently chained to the object whose method caused it to be reported.
• BatchUpdateException: BatchUpdateException is an exception thrown when an error occurs during a batch update operation. In addition to the information provided by SQLException, a BatchUpdateException provides the update counts for all commands that were executed successfully during the batch update, that is, all commands that were executed before the error occurred. The order of elements in an array of update counts corresponds to the order in which commands were added to the batch.
• DataTruncation: DataTruncation is an exception that reports a DataTruncation warning (on reads) or throws a DataTruncation exception (on writes) when JDBC unexpectedly truncates a data value.

The SQLException class extends the java.lang.Exception class and defines an additional method called getNextException(). This allows JDBC classes to chain a series of SQLException objects together. In addition, the SQLException class defines the getMessage(), getSQLState(), and getErrorCode() methods to provide additional information about an error or exception. In general, a JDBC client application might have a catch block that looks something like this:

To understand transaction management, you need to understand the Connection.setAutoCommit() method. Its signature is void setAutoCommit(boolean autoCommit) throws SQLException According to J2SE 1.5, setAutoCommit() sets this connection’s autocommit mode to the given state. If a connection is in autocommit mode, then all its SQL statements will be executed and committed as individual transactions. Otherwise, its SQL statements are grouped into transactions that are terminated by a call to either the commit() or the rollback() method. By default, new connections are in autocommit mode. The following example shows how to handle commit() and rollback() when an exceptionhappens:

In the following example we force the exception to happen: instead of VARCHAR(when creating the cats_tricks table), we type VARZCHAR (the database server will not understand VARZCHAR and therefore it will throw an exception):