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. Dan. On 3 April 2011 20:33, Tom Hobbs <[email protected]> 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" <[email protected]> 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 <[email protected]> wrote: > > > I think that exactly the argume... >
