Exception Handling in EJB – A walk through

As J2EE has become the enterprise development platform of choice, more and more J2EE-based applications are going into production. One important component of the J2EE platform is the Enterprise JavaBeans (EJB) API. Together, J2EE and EJB technology offer many advantages, but with these advantages come new challenges. In particular, any problem in an enterprise system must be resolved quickly. In this blog, we discuss best practices in EJB exception handling for faster problem resolution.

Exception handling is simple enough in a hello-world scenario. Whenever you encounter an exception in a method, you catch the exception and print the stack trace or declare the method to throw the exception. Unfortunately, this approach isn't sufficient to handle the types of exceptions that arise in the real world. In a production system, when an exception is thrown it's likely that the end user is unable to process his or her request. When such an exception occurs, the end user normally expects the following:

A clear message indicating that an error has occurred

·       A unique error number that he can use upon accessing a readily available 

     customer support system

• Quick resolution of the problem, and the assurance that his request has been processed, or will be processed within a set time frame

In this blog we'll talk about exception handling in EJB-based systems. We'll start with a review of exception-handling basics, including the use of logging utilities. Note that this blog assumes you are familiar with J2EE and EJB technologies. You should understand the difference between entity beans and session beans.

Exception-handling basics

The first step in resolving a system error is to set up a test system with the same build as the production system and trace through all the code that led up to that exception being thrown, as well as all the various branches in the code. In a distributed application, chances are that the debugger doesn't work, so you'll likely be using System.out.println() methods to track the exception. While they come in handy, System.out.printlns are expensive. They synchronize processing for the duration of disk I/O, which significantly slows throughput. By default, stack traces are logged to the console. But browsing the console for an exception trace isn't feasible in a production system. In addition, they aren't guaranteed to show up in the production system, because system administrators can map System.outs and System.errs to ' ' on NT and dev/null on UNIX. Moreover, if you're running the J2EE app server as an NT service, you won't even have a console. Even if you redirect the console log to an output file, chances are that the file will be overwritten when the production J2EE app servers are restarted.

For these reasons, rolling your code into production with System.out.printlns included isn't an option. Using them during testing and then removing them before production isn't an elegant solution either, because doing so means your production code won't function the same as your test code. What you need is a mechanism to declaratively control logging so that your test code and your production code are the same, and performance overhead incurred in production is minimal when logging is declaratively turned off.

The obvious solution here is to use a logging utility. With the right coding conventions in place, a logging utility will pretty much take care of recording any type of messages, whether a system error or some warning. So, we'll talk about logging utilities before we go any further.

Logging landscape: A bird's eye view

Every large application uses logging utilities in development, testing, and production cycles. The logging landscape today has a handful of players, and among them two are most widely known. One is Log4J, an open source project from Apache under Jakarta. The other is a recent entry that comes bundled with J2SE 1.4. We'll use Log4J to illustrate the best practices discussed in this blog; however, these best practices aren't specifically tied to Log4J.

Log4J has three main components: layout, appender, and category. Layout represents the format of the message to be logged. Appender is an alias for the physical location at which the message will be logged. And category is the named entity; you can think of it as a handle for logging. Layouts and appenders are declared in an XML configuration file. Every category comes with its own layout and appender definitions. When you get a category and log to it, the message ends up in all the appenders associated with that category, and all those messages will be represented in the layout format specified in the XML configuration file.

Log4J assigns four priorities to messages: they are ERROR, WARN, INFO, and DEBUG. For the purpose of this discussion all exceptions are logged with ERROR priority. When logging an exception in this blog, we will find the code that gets the category (using the Category.getInstance(String name) method) and then invoke the method category. error() (which corresponds to the message with the priority of ERROR).

While logging utilities help us to log the message to appropriate persistent location(s), they cannot fix the root of the problem. They cannot pinpoint an individual customer's problem report from the production logs; this facility is left up to you to build into the system you are developing.

Exception categories

Exceptions are classified in different ways. Here, we'll talk about how they're classified from an EJB perspective. The EJB spec classifies exceptions into three broad categories:

• JVM exceptions: This type of exception is thrown by the JVM. An OutOfMemoryError is one common example of a JVM exception. There is nothing you can do about JVM exceptions. They indicate a fatal situation. The only graceful exit is to stop the application server, maybe beef up the hardware resources, and restart the system.
• Application exceptions: An application exception is a custom exception thrown by the application or a third-party library. These are essentially checked exceptions; they denote that some condition in the business logic has not been met. Under these conditions, the caller of the EJB method can gracefully handle the situation and take an alternative path.
• System exceptions: Most often system exceptions are thrown as subclasses of RuntimeException by the JVM. A NullPointerException, or an ArrayOutOfBoundsException, for example, will be thrown due to a bug in the code. Another type of system exception occurs when the system encounters an improperly configured resource such as a misspelled JNDI lookup. In this case, it will throw a checked exception. It makes a lot of sense to catch these checked system exceptions and throw them as unchecked exceptions. The rule of thumb is, if there isn't anything you can do about an exception, it's a system exception and it should be thrown as an unchecked exception. We will move on to a more detailed discussion of how EJB technology defines and manages different types of exception in the next blog.

CAT Technologies provide IT consulting services to assist our clients with their continually-changing IT environments. Our goal is to help them to continually improve the effectiveness and efficiency of their IT application environments by adopting and evolving towards re-useable software platforms. The gamut of services involves technologies like Java, PHP, Delhi, .Net and scores of tools to cater different  solutions.  Also, there are projects using  Object oriented Programming  like Java and J2EE technologies.

Posted By: S Abdul Razack