You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 25, 2022. It is now read-only.
A simple controller advice was built for BMR core REST API endpoints #122, but this can be improved in several ways:
Since we translate exceptions to error codes in our backend, we need to group certain exceptions together (i.e. set for 5XX, 4XX...etc.) and then respond accordingly depending on environment (i.e. disable stack trace logging on prod)
Currently, we handle the core exceptions that our REST API spec depends on (i.e. 404. 422, 204...etc.) but we do not have logic for inexplicit exceptions that our backend might throw due to unexpected errors (i.e. 5XX) and so they're being being handled automatically by Spring. (stack-trace will always be logged, sensitive information might be leaked...etc.)
Research a suitable error handling method for our BaseController
We might not need to add any additional logic, It might be possible to configure Spring in a way that we can disable extra stack-trace logging on Prod without the need to manually implement this.
Based on @MD485 feedback:
Instead of returning ResponseEntity<Map<String, Any>> we can return ResponseEntity<BaseError>
And a builder pattern would probably make sense for BaseError.
Please note there might be an existing similar type in Spring, so do your research first.
The text was updated successfully, but these errors were encountered:
A simple controller advice was built for BMR core REST API endpoints #122, but this can be improved in several ways:
Since we translate exceptions to error codes in our backend, we need to group certain exceptions together (i.e. set for 5XX, 4XX...etc.) and then respond accordingly depending on environment (i.e. disable stack trace logging on
prod
)Currently, we handle the core exceptions that our REST API spec depends on (i.e. 404. 422, 204...etc.) but we do not have logic for inexplicit exceptions that our backend might throw due to unexpected errors (i.e. 5XX) and so they're being being handled automatically by Spring. (stack-trace will always be logged, sensitive information might be leaked...etc.)
BaseController
Based on @MD485 feedback:
Instead of returning
ResponseEntity<Map<String, Any>>
we can returnResponseEntity<BaseError>
Which would look something like this:
And a builder pattern would probably make sense for
BaseError
.Please note there might be an existing similar type in Spring, so do your research first.
The text was updated successfully, but these errors were encountered: