AmazonServiceException (and Subclasses)

AmazonServiceException is the most common exception that you’ll experience when using the AWS SDK for Java. This exception represents an error response from an AWS service. For example, if you try to terminate an Amazon EC2 instance that doesn’t exist, EC2 will return an error response and all the details of that error response will be included in the AmazonServiceException that’s thrown. For some cases, a subclass of AmazonServiceException is thrown to allow developers fine-grained control over handling error cases through catch blocks.

When you encounter an AmazonServiceException, you know that your request was successfully sent to the AWS service but couldn’t be successfully processed. This can be because of errors in the request’s parameters or because of issues on the service side.

AmazonServiceException provides you with information such as:

si je veux faire par exemple un controle sur les input , si c pas null ou si elles respectent pas une rangée de donnée ,

Map errorPayload = new HashMap();
Map errorPayload = new HashMap();
errorPayload.put(« errorType », « Bad request« );
errorPayload.put(« status », 400);
errorPayload.put(« requestId », context.getAwsRequestId());
String message = « this field is required and should have one of this values code1 code 2 code3 »;
if (POJORequest.getSomeField() == 0) {
errorPayload.put(« message », « required attribute missing : The following required attribute is missing : contactId »); }
try
{
try
{
message = new ObjectMapper().writeValueAsString(errorPayload);
throw new RuntimeException(message); // ici une exception va etre lancer
et message contient la reponse json qui contient d attributs portant
des informations sur la réponse statut code , errorType, status
k , au niveau de l ‘integration
}
catch (JsonProcessingException e) { // TODO Auto-generated catch block e.printStackTrace(); }

 Method Execution /ressource- POST – Integration Response

Map the output from your Lambda function to the headers and output model of the 400 method response.

ici je défini une regex pour détection au niveau de la réponse json , pour dire qd tu recevera une réponse avec le status 400  ou codestatut ou *status peut importe qui match avec la regx .

 

On voit que cette config dit  bien  sous la Section Body Mapping Tempaltes

dans le body de la réponse rend moi ces 3 attributs:

« type » : « $errorMessageObj.errorType »,
« message » : « $errorMessageObj.message »,
« request-id » : « $errorMessageObj.requestId »

 

 

Si je configure pas les code retour dans la response integration:

j’aurai déja ce body de réponse meme si j’aiuen  406 Not Acceptable  , j’aurai le code 200 qui est par default pour le mapping , car j’ai pas fait un mapping pour mon 406 code basé sur le status  ,  on voit bien le status 406mais le status de la réponse interprété en haut est 200 , donc le 406 n’a pas été mappé du coup aws n’encapsule pas le retour et j’aurai le body de response par défaut avec la errorType et sa  stacktrace 

 

 

Solution il faut ajouter

406 comme error code dans Lethod Response puis ajouter

.* »status »:406.* comme regex  ne pas l’oublier aussi au niveau de la Method response Section et ajouter cette templat epour le Body Mapping Template

 

application/json

#set ($errorMessageObj = $util.parseJson($input.path(‘$.errorMessage’)))
{
« type » : « $errorMessageObj.errorType »,
« message » : « $errorMessageObj.message »,
« request-id » : « $errorMessageObj.requestId »
}

on aura alors cette belle réponse :

 

see MonkeyBonkey response for more details

https://stackoverflow.com/questions/31329495/is-there-a-way-to-change-the-http-status-codes-returned-by-amazon-api-gateway