-
Notifications
You must be signed in to change notification settings - Fork 7
Improve HTTP 422 handling #324
Copy link
Copy link
Open
Labels
enhancementNew feature or requestNew feature or requestjavaPull requests that update Java codePull requests that update Java codeplanningEnables automatic issue planning with CodeRabbitEnables automatic issue planning with CodeRabbitpriority:lowNice-to-have improvement. Can be deferred without blocking other work.Nice-to-have improvement. Can be deferred without blocking other work.
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestjavaPull requests that update Java codePull requests that update Java codeplanningEnables automatic issue planning with CodeRabbitEnables automatic issue planning with CodeRabbitpriority:lowNice-to-have improvement. Can be deferred without blocking other work.Nice-to-have improvement. Can be deferred without blocking other work.
Overview
Two follow-up improvements deferred from #319 (PR #323) to keep that change focused. Both relate to making
422 Unprocessable Entityhandling more robust and consistent.1.
GlobalExceptionHandler— Return structured validation errorsCurrent behaviour:
handleValidationExceptionreturns an empty422body (ResponseEntity<Void>).Proposed improvement:
exception.getBindingResult()— either aProblemDetail(RFC 9457, available since Spring 6 / Spring Boot 3) or aMap<String, String>of field → message.Example sketch:
2.
PlayersController.put— Delegate squad number mismatch to validationCurrent behaviour: The inline mismatch check returns
422directly inside the controller method, bypassingGlobalExceptionHandler.Proposed improvement:
PlayerDTO(e.g., a custom@SquadNumberMatchannotation), orSquadNumberMismatchException) and map it inGlobalExceptionHandler,so that all
422responses flow through a single, consistent handler.References
422 Unprocessable Entityfor payload validation errors #319