converting client-side exception to ServiceFailures is confusing
As discussed in Feb. 10 maintenance call, client-side exceptions thrown by libclient_java API calls has been confusing in the v1 java architecture. Because java does not allow an interface method to throw more types of exceptions than is in the interface, we have been transposing exceptions raised in the libclient code (and not received from the services) as ServiceFailures.
The proposal that was adopted is to add a new exception called ClientSideException to all service api methods, that would allow users to know that a 'ServiceFailure' only comes from the service. This should really help with connection errors.
v2 d1_libclient_java already defines and uses a ClientSideException, so we would just move it's definition to d1_common_java, and have it extend BaseException. Then the CSE can be added to the existing v2 and v1 service interface methods.
The impact will be that API method callers will have another exception they need to handle. (should ClientSideException subclass ServiceFailure to minimize application code refactoring?)
#2 Updated by Rob Nahf almost 8 years ago
The original proposal has the flaw that it doesn't fully solve the problem of helping the user diagnose the problem and handle it appropriately. ClientException becomes the new bucket minus true ServiceFailures thrown from MN and CN implementations. it's also inflexible to change.
Want to determine a design where ServiceFailure is subclassed, to allow extra exception classes to be defined non-disruptively.
Compare with HttpClient exception hierarchy - some of their exceptions subclass IOException, while others don't. Determine compatibility with HttpClient's retryHandlingstrategy.