예외(Exception)를 반대하는 개발자들의 주장과 대안
프로그래밍에서 Exception(예외)은 매우 흔한 오류 처리 방식이지만, 이를 반대하거나 제한적으로 사용해야 한다는 주장도 꾸준히 존재합니다. 이 문서에서는 그 주요 논거들과 대안을 정리합니다.
예외 사용을 반대하는 주요 주장
1. 제어 흐름을 숨긴다 (Control Flow Hiding)
- 예외는 함수 시그니처에 드러나지 않음
- 호출자가 어떤 예외가 발생할지 예측하기 어려움
- 코드 흐름이 불명확해짐 → 유지보수 어려움
2. 함수형 프로그래밍에서는 예외 대신 값을 사용
Result,Either,Try등으로 오류를 모델링- 오류가 타입 시스템에 명시되어 컴파일 타임에 예측 가능
- 안정적인 체이닝과 패턴 매칭이 가능
3. 성능 비용 존재
- 스택 추적 생성, GC 부하, 최적화 방해 요소 존재
- 성능 민감한 시스템에서는 오히려 성능 저하 요인
주요 인물 및 커뮤니티의 입장
| 인물/집단 | 입장 요약 |
|---|---|
| Rob Pike (Go 설계자) | Go는 error를 반환값으로 처리하고 예외를 피함 |
| Haskell 커뮤니티 | 오류는 타입으로 표현하고 예외는 피함 |
| Kotlin 함수형 지향 | Result<T>와 sealed class로 오류 모델링 선호 |
| C++ 일부 진영 | 예외 대신 명시적 오류 코드 사용 선호 |
예외를 대체하는 방식
sealed class+when구문Result<T>,Either<L, R>(Arrow 등)Try<T>- 명시적 error code (
Boolean,null등)
실무에서의 현실적 판단
| 관점 | 예외 사용 |
|---|---|
| 명령형 언어 (Java 등) | 널리 사용됨 |
| 함수형 패러다임 | 예외 대신 오류를 값으로 처리 |
| 시스템 프로그래밍 | 성능 및 안정성 위해 예외 최소화 |
| 실무 | 예외 + Result 혼합 전략 자주 사용됨 |
결론
Exception은 강력하고 편리하지만, 코드 가독성, 예측 가능성, 성능 측면에서 단점도 존재합니다.
따라서, 도메인 요구사항과 설계 철학에 따라 예외와 값 기반 오류 처리 방식을 혼합하여 사용하는 전략이 가장 실용적입니다.