[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] Exception Handling of Remote Calls
|
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