0

I am developing a module which internally uses AWS Java SDK client to make EC2 related API calls.

E.g. I have a requirement where I need to attach ENIs to my instance. One of the possible error code in this api call is AttachmentLimitExceeded, I want to execute another logic if this particular error is thrown. I know I can retrieve this error code using AmazonServiceException.getErrorCode() method. But is there any jar which includes all the possible error code strings or exception classes which I can use to handle such error codes and lets say have a switch case depending on each error code?

I do not want to do a hardcoded string matching like 

AmazonServiceException.getErrorCode().equals("AttachmentLimitExceeded");

Since this code will need changes as and when AWS changes their error codes. What is the standard way of including these error codes in third party project?

laughedelic
  • 6,230
  • 1
  • 32
  • 41
WillMcavoy
  • 1,795
  • 4
  • 22
  • 34

1 Answers1

1

I believe that there is no such standard way of handling these error codes.

It depends a lot on the service you use. For example, the mentioned AttachmentLimitExceeded error code appears in the AWSSupportClient with the underlying AttachmentLimitExceededException, so you can catch it if you're using, for example, addAttachmentsToSet method from this service.

But unfortunately, AmazonEC2Client doesn't define such specific exceptions (see the link to the code and compare to the AWSSupportClient above for the evidence). It only has the AmazonEC2Exception with getErrorCode returning String.

Another example of a client with predefined specific exceptions is the AWSSimpleSystemsManagementClient. Look at the subclasses of the AWSSimpleSystemsManagementException.

So the bottom line is that if the service you're interested in doesn't define specific exceptions for different error types, you can

  • either use the getErrorCode method as you mentioned, which is understandably undesirable
  • or not rely on the error codes at all

The choice is tough, but probably you can overcome the problem by configuring some custom request retry policy.

laughedelic
  • 6,230
  • 1
  • 32
  • 41