Java EE applications address a wide range of application types. The use of specific EJB technologies as addressed in earlier chapters is application-specific. There are techniques, while not necessarily EJB-specific, are useful in many EJB applications. This chapter examines a few of these techniques.

We start with exception handling which is an important aspect of any production application. The failure to handle exceptions cleanly can result in an unreliable application. A common technique to assist in dealing with exceptions for simpler applications is to use the println method within a catch block to display exception-related information. Frequently, stack traces are also displayed to the console. This technique is not advisable in a production application for a number of reasons including:

Redirecting the console output to a file may not work because these files are frequently overridden by the server. Logging is the preferred technique and is the process of recording events and information about events to provide an audit trail for the execution of the application. This can be useful for determining the root causes of application failures and to provide feedback on how the application is used. While most servers provide a degree of automatic logging, customized logging is often needed to provide sufficient detail to troubleshoot a problem. The essence of this approach is discussed in the Using logging within an EJB recipe.

Exceptions can be grouped into three categories:

JVM exceptions are thrown by the JVM and there is little the developer can do to handle them. For example, if the JVM runs out of memory then an exception is thrown. The only reasonable thing to do is to restart the server with potentially additional resources.

Application exceptions generally reflect business logic errors that we can usually handle. If an exception is thrown because the account is low on funds, then we can usually remedy the situation in a controlled and predictable manner. Exceptions of this type are derived from the java.lang.Exception class and are called checked exceptions. Checked exceptions must be handled in code otherwise a compile-time error is generated.

System exceptions that derive from the java.lang.RuntimeException class are called unchecked exceptions and are not required to be handled in application code. If they are not handled, then the application will terminate.

The EJB container intercepts EJB method invocations and deals with application and system exceptions. When an application exception occurs, the EJB container will not automatically rollback transactions, which might be present, but allows the application to deal with them.

With system exceptions, the EJB container will automatically rollback any transactions and returns an EJBException to the client. Servers will automatically log system exceptions, though the format of the logs will differ by vendor.

We have seen interceptors used for a variety of purposes in earlier chapters. Their use for logging and exception handling is illustrated in the Using an interceptor for logging and exception handling recipe. While there are many predefined interceptors available, it may be advantageous to create our own. An introduction to creating interceptors is found in the Creating your own interceptor recipe.

Dates and times are frequent components of applications. However, the use of time as supported by Java can be confusing. The Using time within an EJB recipe examines several of the more common uses of time and the mistakes made using time.

Likewise, the use of currency and its localization is important. The How to support currency recipe looks at the techniques used to represent currency and provides an introduction to the use of the BigDecimal class in support of currency.

Lastly, strings are found in most applications. There are efficient and inefficient ways of representing and manipulating strings. The Efficient manipulation of strings recipe examines these issues.