Causing Stack Trace Server Errors Get Lost #127
Assignees
Labels
bug
Something isn't working
Comments
Weltraumschaf
added a commit
to Weltraumschaf/defectdojo-client-java
that referenced
this issue
Jul 12, 2024
…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>
Weltraumschaf
added a commit
to Weltraumschaf/defectdojo-client-java
that referenced
this issue
Jul 26, 2024
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>
Weltraumschaf
added a commit
to Weltraumschaf/defectdojo-client-java
that referenced
this issue
Jul 26, 2024
…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>
Weltraumschaf
added a commit
that referenced
this issue
Jul 27, 2024
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>
Weltraumschaf
added a commit
that referenced
this issue
Jul 27, 2024
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>
Weltraumschaf
added a commit
that referenced
this issue
Jul 27, 2024
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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In very old implementations all causingexceptions were simply ignored. I've fixed that some time ago that causing errors are passed to our custom exception as cause.
But I chosen the type of catched exceptions to narrow: Instead of
HttpClientErrorExceptionwe should catch all possible runtime exceptions from the REST client withRestClientException.The text was updated successfully, but these errors were encountered: