Error Handling and SQL Warnings

JDBC errors are thrown as exceptions. The specific class for representing these errors is java.sql.SQLException. As with any other exception, the appearance of an SQLException signifies that something has gone wrong and needs to be appropriately handled.

SQL warnings are represented by an instance of the java.sql.SQLWarning class that derives from the java.sql.SQLException class. It provides information on database access warnings. Unlike serious exceptions, SQL warnings are silently chained to the object whose method caused it to be reported.

Handling SQLException Errors

SQLExceptions store three pieces of information:

  • A string describing the error.

  • An SQLstate string, which follows the X/OPEN SQLstate conventions. The values of the SQLState string are described in the X/OPEN SQL specification.

  • An integer error code that is specific to each vendor. Normally this is the actual error code returned by the underlying database.

In the previous examples, a try/catch block bracketed the entire JDBC operation. In your catch block, you can handle the exception to suit the needs of your application.

try {
… do JDBC work here …
} catch (SQLException sqle) {

      // Print the summary message of the exception
      System.out.println("JDBC exception encountered: " + sqle);

      // Retrieve and print the SQLState for this SQLException object.
      System.out.println("SQL state string: " + sqle.getSQLState());

      // Print the database specific error code
      System.out.println("Database specific error code: " +
sqle.getErrorCode());
}

Handling SQL Warnings

SQL warnings arise when the DBMS wants to alert you about a possible unintended consequence of your executed SQL statements. For example, if you have received truncated data, SQLWarning returns a DataTruncation warning. SQL warnings are silently attached to the object that generates them. Any relevant JDBC class (including Connection, ResultSet, and Statement) can generate an SQL warning.

Accessing SQL warnings is relatively simple. Each relevant JDBC class includes a method called getWarnings(). Calling this method on any instance of those objects returns the last created SQLWarning. You should always examine any SQL warnings before closing your Statement objects:

try {
… do JDBC work here …

      /* Check for SQL Warnings */
      SQLWarning mySQLW = myStatement.getWarnings();

If (mySQLW != null) {

      // Print the summary message of the exception
      System.out.println("JDBC exception encountered: " + mySQLW);

      // Retrieve and print the SQLState for this SQLException object.
      System.out.println("SQL state string: " + mySQLW.getSQLState());

      // Print the database specific error code
      System.out.println("Database specific error code: " +
mySQLW.getErrorCode());
}
} catch (SQLException sqle) {
      ….
} finally {
      /* Close the Instance of Statement */
      myStatement.close();
}

Note that both SQL warnings and JDBC errors are “chained.” Each exception might have other exceptions nested inside it, if it contains object references to those other exceptions. Nested exceptions can be accessed by calling the getNextWarning() method, which returns an instance of SQLException or SQLWarning, depending upon the exception from which it was called.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.16.48.181