Refactor: Exceptions about aws-sdk-java-v2 HOT 6 CLOSED

Hello @millems ,

Can you please provide more details around this ?

from aws-sdk-java-v2.

@sakky11 We haven't started the design of this quite yet but we have some early impressions of what we think we want to do. Firstly, we want to restructure the exception hierarchy a bit. Right now we have the following structure

AmazonClientException <------ AmazonServiceException <---- DynamoDBException <--- ProvisionedThroughputException

We'd like to break that apart a bit to have separate hierarchies for client vs service exceptions as well as have a common exception for both to simplify catch all scenarios. We also want to revisit the naming so it's not branded with Amazon everywhere (this is important for our API Gateway generated SDKs which we want to be more generic, less AWS specific). So the new hierarchy would look something like this

                             SdkException
                           /              \
                          /                \
         SdkClientException        SdkServiceException        
                      |                       |
                      |                       |
           SpecificClientException      DynamoDBException
                                              |
                                              | 
                                  ProvisionedThroughputException

We've also had problems with name clashes with fields defined in the base AmazonServiceException class and modeled service exception fields so we want to clean that class up a bit and move some of the state/metadata into other objects to limit the number of field names we reserve.

A bit of a stretch goal is to give service teams the ability to annotate which of their exceptions are retryable, which indicate throttling, etc. We currently keep track of a giant list of those in the core module but that's not very scalable and what may be retryable for one service might not for another so it's not very flexible.

Another stretch goal is to revisit our unmarshalling implementation of exceptions. For JSON we use Jackson databind which is pretty limiting and cannot handle exception fields bound to HTTP headers for example.

from aws-sdk-java-v2.

Thanks @shorea
I was thinking to start on this.How can I get started ?

from aws-sdk-java-v2.

@sakky11 That sounds great! I think a good first step would be getting rid of AmazonClientException. In most cases it should be replaced with SdkBaseException but may need to be replaced by SdkClientException in certain situations. Don't know exactly what those situations are but in general, anywhere we accept an AmazonClientException we should probably accept an SdkBaseException instead (retry policy is good example). Anywhere we throw an AmazonClientException we should thrown an SdkClientException instead.

from aws-sdk-java-v2.

Also https://github.com/aws/aws-sdk-java-v2/blob/master/core/src/main/java/software/amazon/awssdk/AmazonServiceException.java#L34 should extend SdkBaseException, anything else that extends AmazonClientException should extend SdkClientException instead.

from aws-sdk-java-v2.

Done as part of #301 and #597

from aws-sdk-java-v2.