It's confusing but consistent.
Your bean implementation should contain no 'throws' of RemoteException.
However, the methods may still return remote exception to the client in
several ways.
1. A method called by your implementation throws one and your method
doesn't handle it (which it normally doesn't.)
2. Your method detects an unrecoverable error, throws a EJBException
which the container sends to the client as a RemoteException. [The container
converts all non-application exceptions to RemoteExceptions.]
3. A network failure.
The sender of a RemoteException is indicating that the receiver may not be
able to recover from the error. However, some receivers MAY choose to
recover in some fashion. So your implementation is allowed to handle
RemoteExceptions, but not required.
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]] On Behalf Of Rickard �berg
Sent: Sunday, July 04, 1999 2:46 AM
To: [EMAIL PROTECTED]
Subject: Re: EJB spec interpretations/assumptions
Hey
Further notes below.
[EMAIL PROTECTED] wrote:
> The new deprecation of enterprise bean method implementations explicitly
> throwing instances of RemoteException makes sense (since RemoteExceptions
are
> for system errors, not business logic errors), but I assume it is still
allowed
> (and not deprecated) for those methods to include RemoteException in their
> method's throws clause as long as their implementations do not explicitly
throw
> new instances of RemoteException. The value of doing that is to avoid
putting
> an unnecessary and useless burden of exception handling on programmers
whose
> method implementations make method calls on EJB object remote interfaces.
For
> those cases where there is nothing constructive the bean developer would
do if
> RemoteException is thrown from such calls, the normal approach would be to
not
> catch RemoteException, and to just let it be implicitly propagated by
including
> RemoteException in the throws clause of your own methods.
I have just read the relevant sections (EJB1.1 Draft 3) and they are
contradictory indeed.
Let's begin with s. 12.2.2, 2nd paragraph:
"The enterprise bean business method and container callback methods may
encounter various exceptions
or errors that prevent the method from successful completion. Typically,
this happens because the
exception or error is unexpected, or the exception is expected but the
EJB Provider does not know how
to recover from it. Examples of such exceptions and errors are: failure
to obtain a database connection,
JNDI exceptions, ***unexpected RemoteException from invocation of other
enterprise beans [14]*** ,
unexpected RuntimeException, JVM errors, etc." (emphasis added)
Note [14] then reads:
"Note that the enterprise bean business method ***may*** attempt to
recover from a RemoteException. The text in this subsection applies
only to the case the business method does not wish to recover from the
RemoteException." (emphasis added)
This might lead one to believe that catching and handling
RemoteException's from other EJB's is optional. But then s. 12.6
("Differences from EJB 1.0") continues with:
"EJB 1.0 specified that the enterprise bean business methods and
containerinvoked callbacks
use the java.rmi.RemoteException to report non-application exceptions.
This practice
is deprecated in EJB 1.1-the enterprise bean methods should use the
***javax.ejb.EJBException***,
or other suitable RuntimeException to report non-application
exceptions." (emphasis added)
>From this it seems as though one have to catch RemoteException when
calling other beans and rethrow as EJBException. The rationale seems to
be that beans themselves do not ever throw RemoteException.
Comments? Other interpretations?
In general I think the use of the word "should" should be changed to
"must". Consistency in the use of "may", "should" and "must" is a must.
:-)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
Homepage: http://www-und.ida.liu.se/~ricob684
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
