Re: [ecf-dev] Exception Handling of Remote Calls

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Peter,

On 6/24/2014 5:23 AM, Peter Hermsdorf wrote:
> Hi,
>
> i have a question regarding exception handling of remote calls which 
> is not specific to ecf, but needs to be solved using ecf ;)
>
> When doing remote calls which result in any kind of exception not 
> related to the remoting itself (eg. exceptions of 3rd party libraries 
> used on server side) they get serialized back to the client which 
> (most of the time) results in ClassNotFound Exception because the 
> library specific Exception class is not known at client side.
>
> I would like to discuss ways to handle this kind of errors:
>
> 1) put all jars also on the client side
>
> that would be the easiest but (from my point of view) also the worst 
> solution. Polluting the client with libraries which he only needs for 
> error display seems wrong to be. besides introducing additional 
> dependencies and larger deployment artifacts
>
> 2) catch "application" exceptions on server side and wrap them into a 
> "general" exception class which is also known on client side
>
> catch Exceptions eg. in
>
> org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.executeRequest 
>
>
> and before deserializing the response back to the client wrap the 
> actual exception into a more general one (including copying call stack 
> etc.)
>
> that would be my preferred solution, but i'm not sure what is the 
> entry point to start with the implementation. Any hints are greatly 
> appreciated.
> Best would be to have an implementation for this kind of error 
> handling which is not provider dependent...
>
> 3) catching all errors in the implementation of the remote service and 
> wrap them into this kind of general Exception
>
> downside of this approach is a lot of boiler plate code in the remote 
> service implementation and a pollution of the implementation itself 
> with code which is only needed for error handling when called from 
> remote....
>
>
> Any other approaches or suggestions how to handle this kind of errors?

I think you've identified the main approaches.    FWIW, I agree that 1 
is undesirable for the reasons you give.

WRT 2 and 3 (catching and wrapping exceptions in host implementation), 
ECF provides two classes to help out with these strategies in 
org.eclipse.ecf.core.status package:

org.eclipse.ecf.core.status.SerializableStatus
org.eclipse.ecf.core.status.SerializableMultiStatus

As the class names imply, these are serializable implementations of the 
Equinox IStatus API.   They also have logic to check for whether the 
constructor-provided Throwable is serializable, and if not then a 
general Exception is substituted in the status object (which is 
Serializable).   Of course they also have the IStatus/MultiStatus 
hierarchical structure which can then be used across remote calls.

This doesn't solve the general problem, but I think it does provide some 
useful structures to implement 2 and 3.   Also, I'm open to adding 
additional support, if other improvements can be identified.

Thanks,

Scott