Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Timestamp field for exception handling #146

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

thisdudkin
Copy link
Contributor

@thisdudkin thisdudkin commented Aug 25, 2024

I've added a new field to display the time at which the exceptional situation occurred.
It seems to look good ;)

@arey
Copy link
Member

arey commented Aug 26, 2024

Thanks for your contibution @earlspilner
By watching the OpenAPI specification https://github.com/spring-petclinic/spring-petclinic-rest/blob/master/src/main/resources/openapi.yml#L1850 it looks like a RestError schema is declared. In the code, we have a RestErrorDto but it doesn't seem to be used. We should use it in all error responses.

What's more, for error handling, I wonder if we shouldn't switch to the RFC 9457 Problem Details for HTTP APIs. We could create an issue. See https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-ann-rest-exceptions.html

@thisdudkin
Copy link
Contributor Author

Thanks for your contibution @earlspilner By watching the OpenAPI specification https://github.com/spring-petclinic/spring-petclinic-rest/blob/master/src/main/resources/openapi.yml#L1850 it looks like a RestError schema is declared. In the code, we have a RestErrorDto but it doesn't seem to be used. We should use it in all error responses.

What's more, for error handling, I wonder if we shouldn't switch to the RFC 9457 Problem Details for HTTP APIs. We could create an issue. See https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-ann-rest-exceptions.html

I'll work on this ;)

@thisdudkin
Copy link
Contributor Author

Last commit introduce RFC 9457 Problem Details in ControllerAdvice, but has small problem:
For some reason it doesn't pass mvn clean install due to lack of JaCoCo test coverage.

To be perfectly honest, I'm not very familiar with JaCoCo, so would welcome advice on how this can be fixed

P.S. From my own perch, I might suggest adding new exceptions when someone is not found (pet, vet, etc.)

@arey
Copy link
Member

arey commented Sep 5, 2024

Hi @earlspilner
It looks like the ExceptionControllerAdvice has not unit test. Thus jacoco plugin fails. To fix it, you have to add an ExceptionControllerAdviceTest class then test the method handlers you had refactored.

In another Pull Request, we could update the openapi specification in order to align it with the RFC 9457.
See https://swagger.io/blog/problem-details-rfc9457-api-error-handling/

In this issue, to keep simple, I propose you could keep usage of the ProblemDetail class from Spring without customize it with non-standard fields. That's what you've done.

ProblemDetail problemDetail = ProblemDetail.forStatus(status);
problemDetail.setTitle(title);
problemDetail.setDetail(detail);
problemDetail.setInstance(URI.create(request.getDescription(false).substring(4)));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: The "instance" member is a JSON string containing a URI reference that identifies the specific occurrence of the problem. See https://datatracker.ietf.org/doc/html/rfc9457#name-instance

We could host our own problem registry. For the beginning, I propose to use the Smartbear registry: https://problems-registry.smartbear.com/
I propose to postpone this change to another PR.

ErrorInfo errorInfo = new ErrorInfo(ex);
return ResponseEntity.status(HttpStatus.NOT_FOUND).body(errorInfo);
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<ProblemDetail> handleMethodArgumentNotValidException(MethodArgumentNotValidException ex, WebRequest request) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

** suggestion**: It looks like the MethodArgumentNotValidException had a body property with the ProblemDetail type.
I wonder if we can reuse it then complete it?
According to its constructor, the details are very generic:

	public MethodArgumentNotValidException(MethodParameter parameter, BindingResult bindingResult) {
		super(bindingResult);
		this.parameter = parameter;
		this.body = ProblemDetail.forStatusAndDetail(getStatusCode(), "Invalid request content.");
	}

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

Successfully merging this pull request may close these issues.

2 participants