@@ -257,7 +257,7 @@ public class BookService {
257257}
258258----
259259
260- Calling the service in your rest end point triggers the `Book` validation automatically:
260+ Calling such service method, e.g. in your rest end point, triggers the `Book` validation automatically:
261261
262262[source, java]
263263----
@@ -276,10 +276,22 @@ public Result tryMeServiceMethodValidation(Book book) {
276276----
277277
278278Note that, if you want to push the validation errors to the frontend, you have to catch the exception and push the information yourselves
279- as they will not be automatically pushed to the JSON output.
279+ as they will not be automatically pushed to the JSON output and will be treated as any other internal server errors .
280280
281281Keep in mind that you usually don't want to expose to the public the internals of your services
282- - and especially not the validated value contained in the violation object.
282+ -- and especially not the validated value contained in the violation object.
283+
284+ [IMPORTANT]
285+ ====
286+ By default, only failing the validation of the constraints defined for the parameters of the REST endpoints
287+ will result in bad request responses with a validation report as a part of the response body.
288+ In any other case, e.g. validation of service methods (be it parameters or return values),
289+ validation of the return value of a REST endpoint, etc., will result in an internal server error (response status code `5xx`),
290+ unless the application code explicitly catches and handles the `ConstraintViolationException` (or a custom `ExceptionMapper` is implemented).
291+ The reasoning behind such behaviour is that only REST endpoint parameters are considered as the user input
292+ and hence can be treated as a bad request (response status code `4xx`),
293+ At the same time, constraint violations in other places result from the application logic execution and, hence, are treated as internal errors.
294+ ====
283295
284296== A frontend
285297
0 commit comments