Skip to content
This repository has been archived by the owner on Nov 25, 2022. It is now read-only.

Improve controller advice error handling #123

Open
u-ways opened this issue Nov 8, 2020 · 0 comments
Open

Improve controller advice error handling #123

u-ways opened this issue Nov 8, 2020 · 0 comments

Comments

@u-ways
Copy link
Owner

u-ways commented Nov 8, 2020

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant