You catch a checked exception in your ejbActivate method. The method is not in a transaction D
We cannot possibly throw any checked application exception from the ejbActivate method, except by throwing the RemoteException. Other than that, no other application exceptions could can thrown at all. But RemoteException is provided for backward compatibility for EJB 1.0. Since we're using EJB 2.0, we shouldn't be throwing RemoteException, hence there's no way we can propagate the checked exception. We should wrap it with EJBException & rethrow it. [A]
a DivideByZero exception occurs as your business logic is running. you do not have a try/catch for this. D
Agreed. This should be a Runtime exception. Hence, the bean should duck it.
you throw a CreateException from your ejbCreate() method. and you realize that you probably cannot safely complete your transaction D
Since we cannot safely complete the transaction, the bean should call setRollbackOnly() and then propagate the CreateException. The bean instance may not be corrupted, hence we do not need to discard it yet. [C, D]
you catch a checked exception in a business method, and realize that your bean is probably corrupt. C, D
An application exception doesn't cause the container to discard the corrupted bean instance. You should wrap the checked exception in EJBException & throw it. This will cause the container to log the exception, mark the transaction for rollback & discard the bean instance. [A]