Regarding throwing java.rmi.RemoteException

[Rajnish Bhasin]

O.k,
Let me get this straight first....
All throughout the Head First EJB Book, i have always read that NEVER THROW A REMOTE EXCEPTION IN YOUR BEAN CLASS.
Now what i wanted to ask is, in case of a Bean Facade Model the session bean acts as a Client to a Entity Bean...
Now acting as a client means declaring the RemoteException in the throws clause or in the catch block...
Becoz when we call actual business methods from a client on a Bean, we always have to handle the RemoteException. And in this case a business method of one bean is acting as the client to another bean, so to declare a RemoteException in this case would be o.k ?
Waiting for a convincing response...

[Walker Rustin]

you said "Now acting as a client means declaring the RemoteException in the throws clause or in the catch block...".
That is not ture. Just because a client is calling a business method of a bean, the client doesn't have to cath RemoteException. The client should catch ONLY and ONLY any app exception if that business method throws. You would have also noticed that the HFEJB suggests that to a client a RemoteException is like a RuntimException.
Hope it gives you something to think over.
- Walk Rustin

[Rajnish Bhasin]

My primary question was...
1)Can we throw or declare java.rmi.RemoteException inside a business method of any kind of bean ? lets say Entity bean...
2)Some beans act as clients for other beans.... like in case of a Session Facade a Session bean Acts like one for the Entity bean.
3)Since java.rmi.RemoteException is aslo a Checked Exception, we need to either:
a)Put it in the throws Clause.
b)Catch it in the catch block.
4)I just need to know why is it mentioned in the HF EJB book that u should never throw/declare a java.rmi.RemoteException in the Bean Class.
[ March 13, 2004: Message edited by: Rajnish Bhasin ]

[Roger Chung-Wee]

Your bean will only throw business exceptions or standard Java exceptions. java.rmi.RemoteException is generated by the Container, which may do something such as throw a RemoteException to a remote client upon encountering a non-Application Exception thrown by a bean.

[MaxPwr Pow]

>My primary question was...
>1)Can we throw or declare java.rmi.RemoteException inside a business >method of any kind of bean ? lets say Entity bean...
if something goes really bad in your bean, wrap it with EJBException and container will deal with it. No, you cannot throw java.rmi.RemoteException from a business method.
>4)I just need to know why is it mentioned in the HF EJB book that u >should never throw/declare a java.rmi.RemoteException in the Bean Class.
because it is a runtime exception that is so serious that it is futile for you to continue from that point onward.

[Roger Chung-Wee]

java.rmi.RemoteException is not a RuntimeException, it is a checked exception.

[Reid M. Pinchback]

Originally posted by Rajnish Bhasin:
My primary question was...
4)I just need to know why is it mentioned in the HF EJB book that u should never throw/declare a java.rmi.RemoteException in the Bean Class.

Bottom line: because the EJB spec says so.
As others have pointed out, getting a RemoteException as a client would be the moral equivalent to getting a RuntimeException; or more accurately, to getting an EJBException (which is what a local client would often receive in situations where the remote client gets a RemoteException).
I'd consider handling the situation by logging the call stack of the RemoteException, extracting the message from the RemoteException, and then throwing a fresh EJBException containing that message.

[Gavin Bong]

If your facade session bean accesses the entity bean via its local interface, then its impossible for you to get a RemoteException, ever.
Pho

[C Chavan]

EJBs are not remote objects. Therefore, one should never throw RemoteException from bean class. If an unrecoverable situation occurs, bean should through an EJBException and container will throw either EJBException or RemoteException based on whether client is local or remote.
[ March 19, 2004: Message edited by: C Chavan ]