에러는 언제든지 발생할 수 있습니다. 중요한 건 어떤 에러가 발생했는지를 명확히 표현하고, 적절하게 처리할 수 있도록 만드는 것이죠.
Java나 Spring에서는 이를 위해 RuntimeException을 상속하여 명확한 명칭의 커스텀 예외를 자주 사용합니다.
왜 RuntimeException을 확장할까?
기본적으로 RuntimeException은 checked 예외와 다르게 컴파일 시점에 예외 처리를 강제하지 않습니다.
이는 비즈니스 로직에서 많이 발생하는 예외 처리에 적합합니다.
그리고 RuntimeException을 확장하여 우리가 정의한 도메인에 맞는 명확한 에러명을 만들 수 있습니다.
예를 들어볼까요?


CApiServiceErrorException 같은 커스텀 예외를 쓰는 이유 & 장점
- 로깅/모니터링에 유리
- 에러의 의도를 명확히 표현할 수 있음
- 에러 핸들링 로직을 깔끔하게 분리 가능

- 재사용성이 좋고, 예외 코드화도 가능

아래처럼 예외 코드를 Enum으로 관리



- RuntimeException을 확장하면 다음과 같은 장점이 있습니다
- UserNotFoundException이라는 이름으로 에러 의미를 직관적으로 전달
- 여러 종류의 예외를 catch해서 상황별로 세분화된 처리 가능
- 공통 Exception 핸들러에서 에러 타입별로 커스텀 응답 처리 가능
- 재사용성이 좋고, 예외 코드화도 가능
'SPRING' 카테고리의 다른 글
| [QueryDsl] QueryDSL의 BooleanBuilder (0) | 2025.04.23 |
|---|---|
| QueryDSL에서 문자열 포함 검색 (LIKE %keyword%) 처리 방법 정리 (0) | 2025.04.22 |
| [Spring] 테스트 코드에 config적용법 (0) | 2024.09.10 |
| [Spring] @ActiveProfiles 사용 가이드 (1) | 2024.09.10 |
| [Spring] Spring Security에서의 AntPathRequestMatcher와 인증 설정 (2) | 2024.09.05 |