river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: [jira] [Created] (RIVER-395) Ill-behaved DiscoveryListener can terminate discovery notifier threads
Date Sun, 03 Apr 2011 20:19:28 GMT
An Error gets wrapped into a ServerError which is a subclass of remote
exception so long as you're using a BasicInvocationDispatcher (see the
description for dispatch).

For other remote stacks you mightn't get such behaviour and as far as I can
see from a quick skim of the docs, it's not explicitly required to behave as
BasicInvocationDispatcher does. Note also that InvocationHandler.invoke
throws Throwable which allows the proxy of a remote service implementation
to return anything it likes for any reason e.g. Error.


On 3 April 2011 20:33, Tom Hobbs <tvhobbs@googlemail.com> wrote:

> I'm not saying you're wrong, I'm saying I don't understand, especially
> given
> that I don't have the code in front of me.  (actually, that's not true but
> a
> this tablet whatsit is awful for looking at code on).
> If I'm cailing a method on a proxy, the worst I can get is a remote
> exception.  Right?  How would a, for example, OutOfMemoryError thrown on a
> remote jvm find its way into my exception handling code without me
> rethrowing it?  At best, wouldn't I only be able to see it via
> remoteException.getCause()?
> I've just never seen what you're describing.  Only ever bad things in the
> re.getCause() method.
> Cheers,
> Tom
> On 3 Apr 2011 20:08, "Dan Creswell" <dan.creswell@gmail.com> wrote:
> Trouble is the Error could have come from a remote JVM, do you want that
> blowing up the local one?
> On 3 April 2011 19:08, Tom Hobbs <tvhobbs@googlemail.com> wrote:
> > I think that exactly the argume...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message