Unified Exception Handling and Assertion Techniques in Java Backend Development

Many Java projects contain abundant try { ... } catch (Exception e) { ... } blocks, resulting in redundant and hard‑to‑read code. The article first shows an "ugly" controller with explicit try‑catch statements and contrasts it with a cleaner version that delegates error handling.

Spring 3.2 introduced @ControllerAdvice and @ExceptionHandler, enabling a centralized way to process exceptions across all controllers. By defining a UnifiedExceptionHandler class annotated with @ControllerAdvice, developers can catch specific exceptions such as BusinessException, BaseException, and framework‑level errors like NoHandlerFoundException or HttpRequestMethodNotSupportedException.

To avoid repetitive null‑checks, the article proposes an assertion interface similar to Spring's Assert. A custom Assert interface provides default methods like assertNotNull(Object obj) that throw a BusinessException linked to an enum constant. Example enum ResponseEnum defines error codes and messages, and a BusinessExceptionAssert interface combines the enum with the assertion logic.

Service code can then use concise assertions, e.g.

ResponseEnum.BAD_LICENCE_TYPE.assertNotNull(licenceTypeEnum);

, eliminating explicit if (obj == null) { throw new ... } checks. The article also shows how to map domain objects to DTOs and how to perform pagination with QueryData wrappers.

The unified handler categorises exceptions into four groups:

Pre‑controller exceptions (e.g., 404, method not allowed) handled by handleServletException.

Business exceptions handled by handleBusinessException and handleBaseException.

Unknown runtime exceptions handled by handleException.

Validation errors (binding/parameter validation) handled by handleBindException and handleValidException.

For production environments the handler can suppress detailed internal messages and return generic codes such as SERVER_ERROR. The article also demonstrates how to force Spring to throw NoHandlerFoundException for missing URLs by setting spring.mvc.throw-exception-if-no-handler-found=true, allowing the unified handler to return a consistent JSON error.

Response objects follow a unified structure: BaseResponse provides code and message; CommonResponse adds a data field; QueryDataResponse includes pagination metadata. Short aliases R and QR simplify usage in controllers.

Testing scenarios cover missing licences, invalid licence types, 404 errors, method‑not‑allowed errors, parameter binding failures, and database exceptions caused by schema mismatches. Each case is captured by the appropriate handler and returns a JSON payload with code and message.

In summary, combining Spring's global exception handling, enum‑based error codes, and assertion utilities yields a clean, maintainable backend codebase where error handling is consistent, extensible, and easy to understand.