When a client calls remove() on a bean that's already been removed, you'll get the same exception you'd see if you called any other business method on a removed bean - remote clients get RemoteException and local clients get EJBException.
But I thought that the clients should get NoSuchObjectException/NoSuchObjectLocalException for remote & local clients respectively.
Agreed but if both RemoteException and NoSuchObjectException are the options (possible answers) in the exam then what should we choose? The reason I'm more confused is bcoz HF book also says that Container is not bound to throw the MOST SPECIFIC Exception (e.g., it can throw CreateException instead of DuplicateKeyException)
I dont think you will get both options in a question because one could argue that both are right and the exam questions are very clear, they avoid such type of confusion. If I get such a question I would choose NoSuchObjectException because this is what the container is supposed to throw. (see page 379 of the spec). But again, it is a subclass of RemoteException, so it is not wrong to say that the remote client will see a RemoteException.
According to the API, all three remove methods would throw RemoveException if the bean/container does not allow the method to be invoked. A RemoteException/EJBException will be thrown to indicate to a remote/local client that the method invocation had failed due to a system-level failure.
When the client made such a request on the bean, the bean should throw NoSuchObjectException/NoSuchObjectLocalException. This being a system exception, will not be caught & will be propagated to the container. The container will then rethrow this as a RemoteException/EJBException back to the client, depending on whether its a remote/local client.
I think the catch here is that the bean does not throw an exception directly to a client. It throws it to the container & the container throws it to the client.
The part whereby the books says that the client may not get the most specific exception, I guess its refering to the application exceptions rather than system exceptions.