Project

General

Profile

Story #6851

converting client-side exception to ServiceFailures is confusing

Added by Rob Nahf about 9 years ago. Updated over 8 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
Category:
d1_common_java
Target version:
Start date:
2015-02-12
Due date:
% Done:

0%

Story Points:
Sprint:

Description

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?)

History

#1 Updated by Rob Nahf about 9 years ago

  • Subject changed from client-side exception handling is difficult, because they are converted to ServiceFailures in API calls to converting client-side exception to ServiceFailures is confusing

#2 Updated by Rob Nahf about 9 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.

#3 Updated by Rob Nahf over 8 years ago

  • Status changed from New to Rejected

this causes more complication than the potential value, and we decided in maintenance standpoint to reject.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)