Mike Swainston-Rainford wrote:
>
> Hi Laird
>
> what I mean is that if you know some of the EJBs are only ever called
> locally then you can ignore all the design idioms for distributed objects.
Ah; sorry for the misunderstanding.
> But for truly remote calls the idioms must be followed. That's what I mean
> by having to *design* two types of 'remote' interface.
The (admittedly controversial) pattern I try to follow if I'm designing
rapidly and don't have time to think about whether or not a given class
will ever be used in a remote or local setting is to treat
RemoteException as though it's a RuntimeException (which, IMHO, it
should have been; there are holy wars raging over this constantly in the
RMI community). I do this by making most if not all of my class'
methods throw it as a matter of course. I believe RemoteException
should be a RuntimeException because recovering from it is frequently
impossible or undesirable; consequently your choices for handling it are
very limited; consequently you should not be forced to catch it.
Does that make sense?
Cheers,
Laird
===========================================================================
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".
