Hi Ohad,
First of all, method1 needs to be ready to handle a
RemoteException from method2. Unless you have a way to
recover from this RemoteException, you should wrap it in
EJBException and rethrow it.
According to 12.2.2 of the spec:
"If the bean method performs an operation that results
in a checked exception that the bean method cannot
recover, the bean method should throw the javax.ejb.EJBException
that wraps the original exception."
If method2 throws an unchecked exception, this won't
be propogated to method1. Method1 is going to get a
RemoteException.
It is possible that the transaction has already
been rolled back by method2, depending on the
transaction attributes of method1 and method2, and
the reason that you are getting a RemoteException
from method2.
Method2 should throw an unchecked exception,
such as EJBException (or, e.g., NullPointerException),
if it encounters a situation from which it can not
recover.
Method2 should throw an application exception
if the problem is a business-logic level problem.
Hope this helps,
Dan
On 24 Apr 00, at 10:43, Ohad Parush wrote:
> Hi Dan,
>
> Thx for your response. I looked back in the list, and found your interesting
> dialog with Richard, regarding the RemoteException and the EJBException,
> which is also related to this issue.
> To clarify things for me a bit let me describe the following scenario:
> If I have bean A which consists of a remote method "method1", which calls
> another method "method2". What type of exception should "method2" throw, so
> that "method1" would wrap it in a EJBException (or RemoteException, for that
> matter), cause the transaction to rollback ("method2" is run in the same
> transaction context as "method1"), and throw it to the client? Should it be
> a RuntimeException ?
>
> Thx,
> Ohad.
>
>
> -----Original Message-----
> From: Dan OConnor [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 23, 2000 6:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Throwing and catching exceptions that are derivatives of
> RemoteEx ception from EJB methods.
>
>
> On 23 Apr 00, at 16:31, Ohad Parush wrote:
>
> Hi Ohad,
>
> Technically, you should not throw RemoteException from your
> bean code, even indirectly. This is deprecated in the 1.1 specs
> (although support for it by the container is mandatory.)
>
> If your code does throw a RemoteException or a subclass thereof,
> it will be treated as a runtime exception by the container (even
> though RemoteException is a checked exception). This means
> that a new RemoteException will be sent to the client, wrapping
> your "non-application" exception.
>
> This behavior is mandated in various places of chapter twelve of the
> specification. There is no way to throw an exception that derives
> from RemoteException in your bean code, and have it reach the
> client.
>
> -Dan
>
>
> > I have an EJB that in one of its remote methods, an Exception that is
> > derived from RemoteException is thrown.
> > This exception is not caught in the bean, so it is thrown outside of the
> EJB
> > server boundries (to the client).
> > However, when I try to catch this exception according to its type name, I
> am
> > unsuccessul,
> > and it is only caught in the "catch(RemoteException)" clause.
> > The exception stack lists my derived exception as the "nested exception".
> > Is there any way to actually throw an exception that derives from
> > RemoteException from the EJB server, so that it will reach the client
> > as that exception (and not as the base class RemoteException) ??
> >
> > Thx,
> > Ohad.
> >
> >
> ===========================================================================
> > 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".
>
> ===========================================================================
> 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".
