@ControllerAdvice for global handling in Spring Boot - Performance & Optimization

Performance: @ControllerAdvice for global handling

MEDIUM IMPACT

This affects server response time and error handling efficiency, impacting how fast and smoothly error responses are generated and sent to the client.

Handling exceptions globally in a Spring Boot application

Spring Boot

@ControllerAdvice
public class GlobalExceptionHandler {
  @ExceptionHandler(UserNotFoundException.class)
  public ResponseEntity<String> handleUserNotFound(UserNotFoundException ex) {
    return ResponseEntity.status(HttpStatus.NOT_FOUND).body(ex.getMessage());
  }
}

@RestController
public class UserController {
  @GetMapping("/user/{id}")
  public User getUser(@PathVariable String id) {
    // fetch user without try-catch
  }
}

Centralizes exception handling, reducing duplicate code and improving maintainability. The server handles exceptions once per type, improving response consistency.

📈 Performance GainReduces CPU cycles spent on repeated try-catch blocks, slightly improving throughput and reducing response time under load.

Handling exceptions globally in a Spring Boot application

Spring Boot

@RestController
public class UserController {
  @GetMapping("/user/{id}")
  public ResponseEntity<User> getUser(@PathVariable String id) {
    try {
      // fetch user
    } catch (UserNotFoundException e) {
      return ResponseEntity.status(HttpStatus.NOT_FOUND).body(null);
    }
    return ResponseEntity.ok(user);
  }
  // similar try-catch in every controller method
}

Duplicating try-catch blocks in every controller method increases code size and maintenance cost, and can slow down request processing due to repeated exception handling logic.

📉 Performance CostAdds redundant exception handling code in every controller, increasing CPU usage and response time slightly under load.

Performance Comparison

Pattern	Code Duplication	CPU Usage	Response Time Impact	Verdict
Try-catch in every controller method	High	Higher due to repeated handling	Slightly slower under load	[X] Bad
Centralized @ControllerAdvice handling	Low	Lower due to single handling point	Faster and more consistent	[OK] Good

Rendering Pipeline

When an exception occurs, Spring routes it to the @ControllerAdvice handler before sending the response. This avoids repeated exception handling logic in controllers and streamlines error response generation.

→Request Handling

→Exception Resolution

→Response Generation

⚠️ BottleneckException Resolution stage can be costly if duplicated in many controllers.

Optimization Tips

1Centralize exception handling with @ControllerAdvice to reduce duplicate code.

2Avoid try-catch blocks in every controller method to save CPU cycles.

3Monitor server logs and response times to verify efficient error handling.

Performance Quiz - 3 Questions

What is a main performance benefit of using @ControllerAdvice for exception handling?

A Delays response by adding extra processing steps

B Reduces duplicate exception handling code and CPU usage

C Increases bundle size by adding more classes

D Improves client-side rendering speed

DevTools: Spring Boot Actuator and Application Logs

How to check: Enable actuator endpoints and monitor logs for exception handling frequency and response times. Use profiling tools to measure CPU usage during error scenarios.

What to look for: Look for reduced duplicate exception logs and faster error response times indicating centralized handling.

Practice

1. What is the main purpose of using @ControllerAdvice in a Spring Boot application?

easy

A. To handle exceptions globally for all controllers in one place

B. To define REST endpoints for the application

C. To configure database connections

D. To create scheduled tasks

Solution

1. Step 1: Understand the role of @ControllerAdvice

   @ControllerAdvice is a special annotation in Spring Boot that allows you to write code to handle exceptions or apply logic across all controllers globally.

2. Step 2: Identify its main use

   Its main use is to centralize exception handling so you don't have to repeat error handling code in every controller.

3. Final Answer:

   To handle exceptions globally for all controllers in one place -> Option A

4. Quick Check:

   @ControllerAdvice = global exception handling [OK]

Hint: Think global error handling for all controllers [OK]

Common Mistakes:

• Confusing @ControllerAdvice with @RestController
• Thinking it configures database or tasks
• Assuming it defines endpoints

2. Which of the following is the correct way to declare a global exception handler method inside a @ControllerAdvice class?

easy

A. @Service public String handleError() { return "error"; }

B. @ExceptionHandler(Exception.class) public String handleError() { return "error"; }

C. @GetMapping public String handleError() { return "error"; }

D. @RequestMapping("/error") public String handleError() { return "error"; }

Solution

1. Step 1: Identify the annotation for exception handling

   The correct annotation to handle exceptions globally is @ExceptionHandler with the exception class specified.

2. Step 2: Check method signature and annotation usage

   @ExceptionHandler(Exception.class) public String handleError() { return "error"; } uses @ExceptionHandler(Exception.class) which is correct inside a @ControllerAdvice class to catch all exceptions.

3. Final Answer:

   @ExceptionHandler(Exception.class) public String handleError() { return "error"; } -> Option B

4. Quick Check:

   @ExceptionHandler = global exception method [OK]

Hint: Use @ExceptionHandler with exception class inside @ControllerAdvice [OK]

Common Mistakes:

• Using @RequestMapping or @GetMapping instead of @ExceptionHandler
• Missing exception class in @ExceptionHandler
• Using @Service annotation incorrectly

3. Given the following code snippet, what will be the HTTP response status when a NullPointerException is thrown in any controller?

@ControllerAdvice
public class GlobalExceptionHandler {
  @ExceptionHandler(NullPointerException.class)
  public ResponseEntity<String> handleNullPointer() {
    return new ResponseEntity<>("Null pointer error", HttpStatus.BAD_REQUEST);
  }
}

medium

A. 400 Bad Request with message "Null pointer error"

B. 500 Internal Server Error with default message

C. 200 OK with message "Null pointer error"

D. 404 Not Found with message "Null pointer error"

Solution

1. Step 1: Analyze the @ExceptionHandler method

   The method handles NullPointerException and returns a ResponseEntity with message "Null pointer error" and status BAD_REQUEST.

2. Step 2: Understand HTTP status returned

   HttpStatus.BAD_REQUEST corresponds to 400 status code, so the response will have status 400 with the given message.

3. Final Answer:

   400 Bad Request with message "Null pointer error" -> Option A

4. Quick Check:

   @ExceptionHandler returns 400 status [OK]

Hint: Check ResponseEntity status in @ExceptionHandler method [OK]

Common Mistakes:

• Assuming default 500 error instead of specified status
• Confusing 400 with 200 OK
• Ignoring the returned ResponseEntity status

4. Consider this @ControllerAdvice class:

@ControllerAdvice
public class GlobalHandler {
  @ExceptionHandler(IllegalArgumentException.class)
  public String handleIllegalArgument() {
    return "illegal";
  }

  @ExceptionHandler(Exception.class)
  public String handleAll() {
    return "error";
  }
}

What is the problem if a NullPointerException occurs in a controller?

medium

A. NullPointerException is not handled and causes server error

B. handleIllegalArgument() method will handle NullPointerException incorrectly

C. handleAll() method will handle NullPointerException correctly

D. Compilation error due to multiple @ExceptionHandler methods

Solution

1. Step 1: Identify exception handlers and their scopes

   handleIllegalArgument() handles IllegalArgumentException only; handleAll() handles all Exceptions as a fallback.

2. Step 2: Determine which method handles NullPointerException

   Since NullPointerException is not IllegalArgumentException, handleAll() will catch it as it handles Exception class.

3. Final Answer:

   handleAll() method will handle NullPointerException correctly -> Option C

4. Quick Check:

   More specific handlers first, then general Exception handler [OK]

Hint: General @ExceptionHandler(Exception.class) catches all others [OK]

Common Mistakes:

• Thinking NullPointerException is unhandled
• Assuming multiple handlers cause compile error
• Confusing which handler matches which exception

5. You want to create a global error handler that returns JSON with error details for all exceptions except ResourceNotFoundException, which should return 404 status with a custom message. How should you implement this using @ControllerAdvice?

hard

A. Use a single @ExceptionHandler(Exception.class) method and check exception type inside to return different responses

B. Use @ControllerAdvice only for ResourceNotFoundException and ignore other exceptions

C. Handle ResourceNotFoundException in each controller separately, and use @ControllerAdvice only for other exceptions

D. Create two @ExceptionHandler methods: one for ResourceNotFoundException returning 404 JSON, another for Exception returning generic JSON with 500 status

Solution

1. Step 1: Understand requirement for specific and general handling

   You need one handler for ResourceNotFoundException with 404 and custom JSON, and another for all other exceptions with generic 500 JSON.

2. Step 2: Implement two separate @ExceptionHandler methods in @ControllerAdvice

   One method annotated with @ExceptionHandler(ResourceNotFoundException.class) returns 404 JSON; another with @ExceptionHandler(Exception.class) returns 500 JSON.

3. Final Answer:

   Create two @ExceptionHandler methods: one for ResourceNotFoundException returning 404 JSON, another for Exception returning generic JSON with 500 status -> Option D

4. Quick Check:

   Separate handlers for specific and general exceptions [OK]

Hint: Use multiple @ExceptionHandler methods for different exceptions [OK]

Common Mistakes:

• Using one method with manual type checks inside
• Handling specific exceptions in controllers, not globally
• Ignoring general exceptions in @ControllerAdvice