Exception Handling

🔍 What Is It?

Spring's exception handling mechanism lets you centralize error handling in one place.

Key components:

• →@ControllerAdvice / @RestControllerAdvice — global handler applied to all controllers
• →@ExceptionHandler(ExceptionType.class) — handles a specific exception type
• →ResponseEntityExceptionHandler — base class that handles Spring MVC exceptions
• →ProblemDetail (Spring Boot 3.x) — RFC 7807 standardized error format

Exception hierarchy to handle:

• →Your custom exceptions (ResourceNotFoundException, BusinessException)
• →Spring validation: MethodArgumentNotValidException (from @Valid)
• →Spring MVC: MethodArgumentTypeMismatchException, MissingServletRequestParameterException
• →Spring Security: AccessDeniedException, AuthenticationException
• →Hibernate: ConstraintViolationException, DataIntegrityViolationException

🎯 Why Do We Need It?

Without global exception handling:

• →Unhandled exceptions return 500 Internal Server Error with a stack trace (security risk)
• →Different parts of the API return different error formats
• →Clients can't reliably parse error responses
• →Debugging is harder because errors aren't logged consistently

With @ControllerAdvice:

• →Consistent JSON error format across all endpoints
• →Correct HTTP status codes (400 for validation, 404 for not found, 409 for conflicts)
• →No stack traces in responses (security)
• →Centralized logging of errors

🏗️ What Happens in Real Projects?

Every production Spring Boot API has a global exception handler. Standard pattern:

• →ResourceNotFoundException → 404 Not Found
• →ValidationException → 400 Bad Request with field errors
• →BusinessException → 422 Unprocessable Entity
• →AccessDeniedException → 403 Forbidden
• →Exception (catch-all) → 500 Internal Server Error (log it, don't expose details)

⚙️ How It Works

When an exception is thrown from a controller (or service/repository called by a controller):

1. Spring's DispatcherServlet catches it
2. Looks for a matching @ExceptionHandler in the current controller first
3. Then looks in @ControllerAdvice classes
4. The first matching handler handles it
5. Returns the ResponseEntity from the handler method

💻 Example

Production Exception Handling — Complete global exception handler with consistent error responses.

// Base exception
public class ApiException extends RuntimeException {
    private final HttpStatus status;
    private final String errorCode;

    public ApiException(HttpStatus status, String errorCode, String message) {
        super(message);
        this.status = status;
        this.errorCode = errorCode;
    }

    public HttpStatus getStatus() { return status; }
    public String getErrorCode() { return errorCode; }
}

// Specific exceptions
public class ResourceNotFoundException extends ApiException {
    public ResourceNotFoundException(String resource, Object id) {
        super(HttpStatus.NOT_FOUND, "RESOURCE_NOT_FOUND",
              resource + " not found with id: " + id);
    }
}

public class BusinessException extends ApiException {
    public BusinessException(String errorCode, String message) {
        super(HttpStatus.UNPROCESSABLE_ENTITY, errorCode, message);
    }
}

public class DuplicateResourceException extends ApiException {
    public DuplicateResourceException(String resource, String field, Object value) {
        super(HttpStatus.CONFLICT, "DUPLICATE_RESOURCE",
              resource + " already exists with " + field + ": " + value);
    }
}

🤔 Common Confusions

🚨 Common Production Issues

✅ Best Practices

🏛️ Architect's Note

💬 Frequently Asked Questions

🎯 Key Takeaways

🔗 Related Topics

🎯 Practice this topic in interviews

↗ Where this topic fits