Hi!
Ole Husgaard wrote:
> Not that it matters much for this discussion, but
> there is something I just need to get out of my
> system:
>
> <RANT TOPIC="RemoteException">
> I don't like this exception!
> It is checked so it has to be declared anywhere it
> might be thrown, and I don't like it. I know Suns
> arguments for making this a checked exception, but
> the same arguments apply to out-of-memory conditions
> so why isn't OutOfMemoryError a checked exception?
This is not the same thing. Have you read the Sun Labs paper on why RE
is checked?
> This exception is simply used in too many places;
> immediately comes into mind:
> - Transient communication failures.
> - Permanent communication failures.
> - Transient server failures.
> - Permanent server failures.
> - EJB reentrancy failures.
> - Unexpected EJB bean failures.
> And what do we have to distinguish between these
> cases?
Lots of different subclasses of RemoteException. Just because it is a
RemoteException doesn't mean that it *is* a RemoteException. It could
just as well be a ConnectException, or a TransactionRolledBackException,
etc.
> Sometimes we have a reference to the "real"
> exception that happened, but in many cases we only
> have a string that may vary between implementations.
>
> And the EJB specifications are not very helpful in
> specifying this proper: Instead of mandating that
> a particular subclass be thrown they just say
> "RemoteException must be thrown" in most cases.
>
> How nice it would be if EJB specified
> "ReentrancyException extends RemoteException" so
> that a client could just retry a call to a busy
> EJB instance. Currently EJB just says that a
> RemoteException be thrown in case of illegal
> reentrancy, but it is really impossible for
> a client to distinguish this case from the huge
> number of other cases where a RemoteException
> is also thrown!
> </RANT>
True, there should be more rules for what subclasses should be thrown.
Other than that I think that RE should and must be a checked exception,
for the reasons mentioned in the Sun Labs paper on the subject.
/Rickard
--
Rickard Öberg
Email: [EMAIL PROTECTED]
