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>
Which would look something like this:
internal class BaseError(
status: Int,
path: String,
timestamp: Instant,
message: String,
// ...
)
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.
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.)
BaseControllerBased 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.