Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Concentrate on the Java Exceptions that Matter to Your Application : Page 2

Using custom exceptions that separate application from system exceptions enables you to concentrate on handling only the exceptions that are meaningful to your application.


advertisement

A Classic Example: Getting a Database Connection

When developing Java applications that interact with a relational database, you use the JDBC (Java database connectivity) API. The first step is always getting a database connection object (java.sql.Connection). Usually, the code required to get a connection object is placed in one method that other methods performing CRUD (Create, Read, Update, Delete) operations on a database use. Listing 1 shows how to write such a method. The code displays an Oracle database connection string, but it could be any database.

Listing 1: How a Database Connection Is Usually Retrieved
public static Connection getConnection() throws ClassNotFoundException, SQLException { Connection connection = null; // Load the JDBC driver for your database String driverName = "oracle.jdbc.driver.OracleDriver"; Class.forName(driverName); // Create a connection to the database, usually those values are retrieved from a properties file String serverName = "127.0.0.1"; String portNumber = "1521"; String sid = "mydatabase"; String url = "jdbc:oracle:thin:@" + serverName + ":" + portNumber + ":" + sid; String username = "username"; String password = "password"; connection = DriverManager.getConnection(url, username, password); return connection; }

The problem with using this version of the getConnection() method is that you have to handle java.lang.ClassNotFoundException and java.sql.SQLException, and you can't do much except throw these exceptions again. From your application's perspective, either of them prevents a database connection from being retrieved.



An updated version of the getConnection() method avoids your having to handle those exceptions (see Listing 2). This version eases the burden of handling exceptions whenever getConnection() is called by not throwing exceptions. However, returning null creates unexpected runtime behavior.

Listing 2: An Updated Version of the getConnection() Method
public static Connection getConnection() { Connection connection = null; try { // Load the JDBC driver for your database String driverName = "oracle.jdbc.driver.OracleDriver"; Class.forName(driverName); // Create a connection to the database, usually those values are retrieved from a properties file String serverName = "127.0.0.1"; String portNumber = "1521"; String sid = "mydatabase"; String url = "jdbc:oracle:thin:@" + serverName + ":" + portNumber + ":" + sid; String username = "username"; String password = "password"; connection = DriverManager.getConnection(url, username, password); return connection; } catch (ClassNotFoundException e) { // Could not find the database driver } catch (SQLException e) { // Could not connect to the database } // return null in case of any exception return null; }

A Business Classification for Java Exceptions

Looking back at Listing 1, the two exceptions thrown there are the kind of exceptions that should not occur once development is over. In fact, when such exceptions occur while your application is in production, your application cannot recover from them. An administrator must intervene if it is a database or network issue, otherwise a Java programmer has to get involved. This means all the code you wrote to handle those exceptions is of little practical value.

This leads to the classification of exceptions from an application development view:

  1. Application exceptions—Exceptions that are related to the application's business and must be handled properly
  2. System exceptions—Exceptions resulting from technical issues, whether they are programming-related or infrastructure-related (database or network)

Application exceptions are usually meaningful to the end user. When they are handled, a proper message (depending on the business requirement) is displayed, telling the application user what went wrong and what he/she can do to recover from it (like changing the data he/she entered).

As an example, consider a "user registration" page containing a field to enter user name, which must be unique. This is usually done by applying a database unique constraint to a table column. When the user enters an existing user name, a java.sql.SQLException that wraps the unique constraint violation message produced by the RDBMS is generated. You are required to return an appropriate message to the user in this case.

System exceptions cannot be recovered from by the end user; they can be handled only by technical staff. For example, if the database fails or there is a programming error, an end user can do nothing about it. System exceptions are unlikely to occur once your application reaches a stable state.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap