Timestamp field for exception handling

[thisdudkin]

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

[arey]

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]

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]

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]

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.

[arey]

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.

[arey]

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.");
	}