#127 Improve Error Handling for Failed DefectDojo API Requests #128
Conversation
…quests Two Problems: 1. We do not pass consequently the causing exception to our own custom exception. 2. We do not catch all possible REST client runtime exceptions. Fixed by consequent logging and passing ofthe origin exception as cause of our own excpetion. Also catching a more generic exception type totach all possible errors. Signed-off-by: Sven Strittmatter <sven.strittmatter@iteratec.com>
|
|
||
| return response.getBody(); | ||
| try { | ||
| ResponseEntity<T> response = restTemplate.exchange( |
There was a problem hiding this comment.
Did you intentionally only add this for the GET requests?
The error handling for the other http methods seems to be the same
There was a problem hiding this comment.
🤔No. This means that any error handling is missing on non-GET bc I simply grepped HttpClientErrorException 😬
|
|
||
| return response.getBody(); | ||
| } catch (RestClientException e) { | ||
| log.error("Exception while getting data: {}", e.getMessage()); |
There was a problem hiding this comment.
Whats in a message for a request client exception?
Is that enough for users to understand what request failed? Does it include the http method and url of the request?
There was a problem hiding this comment.
That's a common pattern in Java that you simply log the exception message, if the exception is rethrown with the origin exception as cause because the full exception handling is done where the rethrown exception is catched. It's quite debatable if this log message is really necessary.
The conatenation will be done always, also if debug level is not logged. So we should alwyas use parameterized log statements. Signed-off-by: Sven Strittmatter <sven.strittmatter@iteratec.com>
…P Methods In previous commits only GET requests were covered with proper exception handling. This adds rethrow of our own custom exception with the originating error as cause, like already implemented for GET requests. Signed-off-by: Sven Strittmatter <sven.strittmatter@iteratec.com>
Two Problems:
Fixed by consequent logging and passing ofthe origin exception as cause of our own excpetion. Also catching a more generic exception type totach all possible errors.