in progress
Addresses CCSDK-2791 - Getting issue details... STATUS
Background
The error response content is extremely important for issues troubleshooting.
Depending on requirements the error message content may include
- error message
- error code (could be customer specific)
- error details (string or structured)
- error message parameters for message localization purposes
The error message structure is a part of REST API so it's expected the message creation
expected to be based on model generated from OpenAPI configuration. It means the
the message builder is expected to be a part of REST API component (cps-rest).
From other hand the nature of a possible error (e.g. ) and the source module (the initial exception
is thrown from) is quite variable. So it requires some unified and clear way for error information
delivery from service level (cps-service component) and below (e.g. persistence level). Also both
error message and error information delivery expected to be easily extendable.
Proposal
The error message builder is usually implemented as an Exception handler (\@ControllerAdvice
tied to rest controller implementation) being part of rest module due to dependencies
on generated artifact.
To minimize the variety of cases to handle the project specific Exception to be introduced on
service level. The customer specific cases to be implemented via Exception inheritance.
cps-rest
- Error message model artifact - generated from OpenAPI spec on build
- error message builder - uses current module exceptions and the CpsException
(plus sub-types) returned thrown by cps-service
cps-service
- CpsExeption artifact as a part of SPI
To discuss/decide
- The Error message artifact vs OpenAPI - generated from or predefined (with annotation)
- Type of CpsException - checked vs unchecked