It’s all about expectations...

Exception handling in EJB (or Java in general) centers on expectations. You hope that everything works correctly. You hope that you don’t get a runtime exception. But you take risks. So you expect that some things will go wrong. The key is in knowing what those things are, and what you can do to recover.

Most of the time, the things that can go wrong are pretty obvious. You do a JNDI lookup, but the object isn’t there. You try to connect to a naming service, and can’t. You try to connect to the database and can’t. You try to create a new entity bean, and the insert fails because you have a duplicate primary key. And for each of those, you can write a catch block that nows how to deal with the specific problem you have. Can’t connect to the naming service? Maybe you have a second naming service to try. Can’t connect to the database? Maybe you can try using a local cache for now, until you can re-establish your connection. Can’t do the insert? Try again, using a different primary key.

When you provide a catch block for a risky method call, you’re saying that you expect something specific might go wrong. Almost every exception for which you provide a catch block is an exception that you expect. So you might, for example, expect a NamingException or a FinderException or a CreateException.

Wrapping a risky method call in a try/catch tells the compiler (and your design) that you expect that certain things might go wrong.

You hope that everything works correctly, ...

Get Head First EJB now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.