• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RemoteException

 
Will Hunt
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which is true when an entity bean's client receives a java.rmi.RemoteException?

A The client must be local.
B A checked exception was propagated from the bean.
C The client is not required to handle or declare the exception.
D This exception can never occur if the client is in a transaction.


What would be the answer and why ?
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Will Hunt:
Which is true when an entity bean's client receives a java.rmi.RemoteException?

A The client must be local.
B A checked exception was propagated from the bean.
C The client is not required to handle or declare the exception.
D This exception can never occur if the client is in a transaction.


What would be the answer and why ?



I think is D (also because there is no other possibility) and here follows my reason:

1) It cannot be A, because RemoteException is a way for the container to inform a remote client that 'something went wrong' on the server;

2) It cannot be B, because in case of checked exceptions, the container propagates the checked exception to the client as it is, not re-wrapping it in a RemoteException;

3) Remote clients needs to handle or declare the RemoteException on a remote method invocation. Is the way Remote Objects have to inform the client that it's dealing with a remote object. Remember that with RMI, the client point of view is that it is performing a normal method invocation, because RMI goal is to realize network transparency for the client when it comes at invoking remote methods;

4) So, it must be D. The reason is that a RemoteException, although is a checked exception, is thrown by the container when a system exception (read: something that the client didn't expect) happened on the server. This means that on the server a runtime exception must have occurred. When a runtime exception occurs, the server rolls-back the transaction (therefore the client is not in a transaction any more), kills the bean instance (not the underlying entity), logs the error, and throws a RemoteException to the client.

If it's not D...Well, I'm in trouble
:roll:
 
Will Hunt
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not sure, according to SUN the answer is C. So I was thinking may be it is typo on their side and it is EJBException.
Because you have to declare or deal with the RemoteException on the clint side , if it is a remote client.
 
Dan T
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i thought i remeber reading that altough RemoteException is a checked exception from the beans pt of view but from the Client's view, it is a system exception, therefore we do not have to handle it

So I guess we have to 'catch' it, but dont have to implement how to recover from it, since it isnt recoverable. The client has no clue what is happening.
[ August 01, 2004: Message edited by: Ryan Wong ]
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My understanding of 'handle' is to wrap the exception in a try/catch block. My understanding of 'declare' is to declare the exception in the method signature.

Because Remote interfaces have to declare RemoteException for each method, remote clients will have to 'handle' or 'declare' the RemoteException in their method.

RemoteException is a system exception in the logical meaning of it (i.e. something that the client didn't expect to happen). But technically, they are checked exceptions, and as checked exceptions they must be either handled or declared.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic