Laird Nelson wrote:
> david sims wrote:
> > On Wed, 12 Apr 2000, Richard Monson-Haefel wrote:
> > > Laird Nelson wrote:
> > > > Was it the specification's intent to *replace* the throwing of
> > > > RemoteExceptions with the throwing of EJBExceptions, or was it its
> > > > intent to *augment* it?
> > > The intent is to replace it. EJBException should be thrown from EJB 1.1 beans
> > > instead of RemoteException. RemoteException was left in the method signatures
> > > to support backward compatibility with 1.0 beans.
> > But of course, should one bean call another bean and encounter network
> > problems, a RemoteException will be thrown and the bean should propagate it
> > out, one way or another. So it's not to say that we should never, ever have to
> > deal with RemoteExceptions again.
>
> OK; thanks for both of your feedback (feedbacks?). Richard, I assume
> that when you say that "EJBException should be thrown from EJB 1.1 beans
> instead of RemoteException", you are speaking only of the bean class,
> correct? I see no way to remove RemoteException from the signatures of
> the remote or home interfaces.
Yes that is correct. Thank you for the clarification. The client API will always
throw RemoteException for every business method. I was referring only to the
exception thrown from ejb bean methods to the container.
>
>
> Finally, I suppose that if I'm following the (excellent) suggestion of
> implementing a business interface (a superinterface of the bean class
> and the remote interface), I should simply not declare in the bean
> class' implementations of the business interface methods that they throw
> RemoteException. Or, to put it less confusingly, it should be the case
> that RemoteException should not show up in any throws clause in a bean
> class. Correct?
>
This depends on how you want RemoteException thrown by other beans to be handled.
Transactions in EJB 1.1 are always rollback in the event of a EJBException is thrown
but not always for RemoteException. As David pointed out, you can choose to propagate
the RemoteException thrown by another bean to the client.
Personally, I don't think its a good idea to blindly propagate RemoteExceptions (and
other system exceptions) thrown with in a bean method to the client. You should
attempt to handle the exception in an intelligent manner and throw an application
exception if you can not recover or an EJBException if the problem is serious and
requires the termination of the transaction and the eviction of the instance.
<plug>
This stuff is complicated to say the least, which is why the O'Reilly EJB book has
such an entire chapter dedicated to Transactions and exception handling.
</plug>
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition
Published by O'Reilly & Associates
http://www.EjbNow.com
===========================================================================
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".
