IndoKnight, what a great shell you gave about how Exception semantics within Java EE work.
There are two lines: the "bean provider", that is, you and I should be aware of exceptions in Java EE:
Your bean is completely free to recover from any type of exception or error at your discretion with respect to other restrictions that may be a bean. If you recovered from the exception, then congratulations - there are no more problems =)
An appropriate restriction may be, for example, that "enterprise beans using container-managed transaction delimitation should not use any transaction management methods that interfere with the container transaction demarcation boundaries" to indicate the Java EE 7 tutorial p. 48-2 (whether you want to programmatically set the rollback of a container-managed transaction, use EJBContext.setRollbackOnly () ).
You are also not recommended, like any other Java application, to handle Throwable or Error , which are reset from a really low level. RuntimeException theoretically calculated in this category, since it so well signals a “developer error” that it is “completely completely unexpected,” but we all know that it is not.
Basically, an unforeseen exception (a runtime exception + other shit that we assume comes from someone else) is considered unacceptable from your code and should be handled by the server. The server must handle the exception (see the EJB 3.2 specification , p. 204) by printing something about it in the log (I will go into details a bit later!).
Read more ..
You asked (and this is what I believe or believe):
Are all of the above application exceptions thrown directly to the EJB client?
Yes. And the transaction (if it is active) should not be rolled back unless you explicitly state that it should use the rollback attribute ApplicationException . The exclusion of Java metadata is a very natural thing. Java EE does not intend to demolish this programming model. So let's throw checked exceptions as you like, forcing clients to try them or mark runtime exceptions as application exceptions and throw them too. Happy throw!
If system exceptions are wrapped inside javax.ejb.EJBException before throwing to the client, then is javax.ejb.EJBException treated as a system exception?
Yes , but not for the reason you provide. To be clear, there is no such thing as a SystemException. Just a bizarre wording describes those exceptions that most beans did not appear there, and most likely they come from an EJB container. There must be an EJBException in your code. Doing this would probably only hinder the Server mind. You also cannot annotate an exception like @ApplicationException, since you are not the owner of the code, it is provided by the Java EE API. You can extend an EJBException, but it doesn't make sense to mask your code as part of a server-side code base. Most importantly, since an EJBException extends a RuntimeException , I find it safe to classify an EJBException as a "system-level exception."
Beware of the devil
Some remote clients will receive a RemoteException instead of an EJBException.
Interceptors , which you might not even have suspected would be a huge corporate project, could have swallowed the exceptions coming from your active transaction method, even if you never had any plans to let him do it.
I bet you think the thrown exception is always thrown using Throwable.getCause () . Note that the EJB 3.2 specification does not say that a container should or should leave a link to a suppressed reason. In fact, the only thing the container needs to do is to register an exception. Then, if the bean is not single, the bean instance should be discarded and never be used again. In addition, if the bean is a message-driven bean, then the original exception must be wrapped. How to exclude the "exception" exception is not indicated. A super portable cool code should probably look at the Throwable.getCause () and Throwable.getSuppressed () methods . Do not blindly expect your processing code to always find the original exception.
Asynchronous methods (public session bean methods annotated @Asynchronous ) that return void cannot propagate an exception to its client. Therefore, they should not declare or exclude application exceptions (see the EJB 3.2 specification ). Please note that when calling the asynchronous method, it may happen that the server cannot provide streaming resources to serve your request, and if so, it needs to execute the command ... EJBException (page 48)!