Validation error responses in Spring Boot - Step-by-Step Execution

Concept Flow - Validation error responses

Client sends request with data

↓

Spring Boot validates data

↓

Data valid

↓

Process request

↓

Send success

↓

Client receives response

The client sends data, Spring Boot checks it, then either processes it or sends back validation errors.

Execution Sample

Spring Boot

@PostMapping("/users")
public ResponseEntity<?> createUser(@Valid @RequestBody User user, BindingResult result) {
  if (result.hasErrors()) {
    return ResponseEntity.badRequest().body(result.getAllErrors());
  }
  return ResponseEntity.ok(userService.save(user));
}

This code checks if user data is valid and returns errors if not, or saves the user if valid.

Execution Table

Step	Action	Validation Result	Branch Taken	Response Sent
1	Receive POST /users with user data	Not checked yet	N/A	N/A
2	Validate user data	Valid	No errors branch	Proceed to save user
3	Save user data	N/A	N/A	200 OK with saved user
4	Receive POST /users with invalid user data	Invalid	Has errors branch	400 Bad Request with error list
5	Return validation errors	N/A	N/A	400 Bad Request with error list

💡 Execution stops after sending either success or error response.

Variable Tracker

Variable	Start	After Validation	After Branch	Final
user	null	User object from request	Same	Same
result.hasErrors()	false	false or true depending on data	Checked	Used to decide response
response	null	null	Set to 200 OK or 400 Bad Request	Sent to client

Key Moments - 2 Insights

Why do we check result.hasErrors() before saving the user?

Because if validation fails, we must not save invalid data. The execution_table rows 2 and 4 show the branch decision based on validation.

What does the response contain when validation fails?

It contains a 400 Bad Request status and a list of validation error messages, as shown in execution_table rows 4 and 5.

Visual Quiz - 3 Questions

Look at the execution_table, what response is sent at step 3?

A 500 Internal Server Error

B 400 Bad Request with error list

C 200 OK with saved user

D No response sent

💡 Hint

Check the 'Response Sent' column at step 3 in the execution_table.

At which step does the validation detect invalid data?

A Step 4

B Step 1

C Step 2

D Step 5

💡 Hint

Look for 'Invalid' in the 'Validation Result' column in the execution_table.

If result.hasErrors() is false, what happens next?

A Return 400 Bad Request

B Save user and return 200 OK

C Throw exception

D Ignore request

💡 Hint

See the branch taken when validation is valid in execution_table step 2.

Concept Snapshot

Spring Boot validates incoming data automatically.
Use @Valid and BindingResult to check errors.
If errors exist, return 400 Bad Request with error details.
If no errors, process and return 200 OK.
This keeps data clean and user informed.

Full Transcript

When a client sends data to a Spring Boot server, the server checks if the data is valid using annotations like @Valid. The BindingResult object holds any validation errors. If errors exist, the server sends back a 400 Bad Request response with details about what was wrong. If the data is valid, the server processes it, such as saving a user, and sends back a 200 OK response with the saved data. This flow ensures only good data is saved and users get clear feedback on mistakes.

Practice

1. What is the main purpose of validation error responses in a Spring Boot application?

easy

A. To speed up the application startup time

B. To inform users about incorrect input so they can fix it

C. To log errors only for developers without user feedback

D. To automatically correct user input without notification

Solution

1. Step 1: Understand validation error responses

   Validation error responses are designed to tell users what input is wrong so they can correct it.

2. Step 2: Identify the purpose in Spring Boot context

   Spring Boot uses validation error responses to provide clear feedback to users, improving user experience.

3. Final Answer:

   To inform users about incorrect input so they can fix it -> Option B

4. Quick Check:

   Validation error responses = user input feedback [OK]

Hint: Validation errors help users fix input mistakes [OK]

Common Mistakes:

• Thinking validation errors speed up startup
• Assuming errors are only for developer logs
• Believing errors auto-correct input silently

2. Which annotation is used in Spring Boot to trigger validation on a request body object?

easy

A. @Valid

B. @Autowired

C. @RequestBody

D. @Controller

Solution

1. Step 1: Identify annotation for validation

   The @Valid annotation tells Spring Boot to validate the object passed in the request.

2. Step 2: Differentiate from other annotations

   @RequestBody binds the request body, @Autowired injects dependencies, and @Controller marks a class as a controller, none trigger validation.

3. Final Answer:

   @Valid -> Option A

4. Quick Check:

   Validation trigger = @Valid [OK]

Hint: Use @Valid to activate validation on input objects [OK]

Common Mistakes:

• Confusing @RequestBody with validation trigger
• Using @Autowired for validation incorrectly
• Thinking @Controller triggers validation

3. Given this Spring Boot controller method snippet, what will be the HTTP response status if validation fails?

@PostMapping("/users")
public ResponseEntity<String> createUser(@Valid @RequestBody User user) {
    return ResponseEntity.ok("User created");
}

medium

A. 400 Bad Request

B. 200 OK

C. 500 Internal Server Error

D. 404 Not Found

Solution

1. Step 1: Understand validation failure behavior

   When validation fails on a @Valid annotated object, Spring Boot returns a 400 Bad Request by default.

2. Step 2: Check the method response

   The method returns 200 OK only if validation passes; failure triggers automatic 400 response.

3. Final Answer:

   400 Bad Request -> Option A

4. Quick Check:

   Validation fail status = 400 Bad Request [OK]

Hint: Validation failure returns 400 Bad Request by default [OK]

Common Mistakes:

• Assuming 200 OK even if validation fails
• Thinking validation failure causes 500 error
• Confusing 404 Not Found with validation errors

4. What is wrong with this Spring Boot exception handler for validation errors?

@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<String> handleValidationError(MethodArgumentNotValidException ex) {
    return ResponseEntity.badRequest().body(ex.getMessage());
}

medium

A. It does not use @Valid annotation

B. It uses the wrong exception class for validation errors

C. It should return HTTP status 500 instead of 400

D. It returns a plain message string instead of detailed field errors

Solution

1. Step 1: Analyze the exception handler response

   The handler returns only the exception message string, which is not user-friendly or field-specific.

2. Step 2: Understand best practice for validation errors

   Best practice is to return a JSON with detailed field error messages for clarity, not just a plain string.

3. Final Answer:

   It returns a plain message string instead of detailed field errors -> Option D

4. Quick Check:

   Validation error response should be detailed JSON [OK]

Hint: Return detailed JSON, not plain strings, for validation errors [OK]

Common Mistakes:

• Using wrong exception class (MethodArgumentNotValidException is correct)
• Returning HTTP 500 instead of 400
• Confusing @Valid usage with exception handling

5. You want to customize validation error responses to return JSON with field names and messages. Which approach correctly achieves this in Spring Boot?

hard

A. Use @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) on the controller method to handle validation errors

B. Add @Valid to the controller method and rely on default error messages without customization

C. Create a @ControllerAdvice class with @ExceptionHandler for MethodArgumentNotValidException that extracts field errors and returns a JSON map

D. Catch Exception in the controller method and return a plain string message

Solution

1. Step 1: Understand how to customize validation error responses

   Using a @ControllerAdvice with an @ExceptionHandler for MethodArgumentNotValidException allows extracting field errors and returning custom JSON.

2. Step 2: Evaluate other options

   Add @Valid to the controller method and rely on default error messages without customization uses default messages without customization; C uses wrong status; D returns plain string, not JSON.

3. Final Answer:

   Create a @ControllerAdvice class with @ExceptionHandler for MethodArgumentNotValidException that extracts field errors and returns a JSON map -> Option C

4. Quick Check:

   Custom JSON errors = @ControllerAdvice + @ExceptionHandler [OK]

Hint: Use @ControllerAdvice and @ExceptionHandler for custom JSON errors [OK]

Common Mistakes:

• Relying on default messages without customization
• Using wrong HTTP status for validation errors
• Returning plain strings instead of JSON