Exceptions and Transactions

Packaging Exceptions

The majority of this chapter has been concerned with describing the different exception types and looking at how a transaction that is in progress is affected when an exception is thrown. That information by far is the most important for you to understand because knowing how the container expects you to throw and catch exceptions is the only way you can write correct programs that are resilient when faced with unexpected errors. This last section departs from that focus and looks at a simple deployment issue related to the exception classes you define.

As discussed in this chapter, you should always create your own exception classes so you can precisely report error conditions in the systems you build. When you do this, one of the first decisions you have to make is that of where to put these exceptions within your package hierarchy. It might not sound like a big issue at first, but as with any class, the package assignment for an exception should provide information about its intended use. The distributed nature of architectures like EJB also affects packaging choices. Client-side code has to have access to the interfaces that define the services provided to it by the application server, but you don't want to expose too much of the server-side structure because it begins to hint at implementation details.

When you develop an exception class for an EJB application, you need to decide whom that exception is intended to serve. In the architecture proposed throughout this book, a Web tier client only accesses session beans in the application tier. Using this guideline, exceptions that are intended to report errors to the Web tier should be packaged in such a way that they have no coupling to the entity beans or their interfaces. Going further, an exception class has more potential for reuse if it isn't tied to the session beans, either. By packaging your exceptions separately from your enterprise beans, it makes it easier for you to throw these exceptions from your entity beans to your session beans. You then can rethrow them to your clients or throw an alternative exception, depending on the needs of your application.

The auction example adheres to this approach by defining application exceptions in packages such as com.que.ejb20.auction.exceptions . With this structure, the EnglishAuction entity bean can use InvalidBidException , even though this same exception class is used by the AuctionHouse session bean to report application errors to the Web tier.