자바의 체크드 예외 재고찰: 저평가된 타입 안전성 기능
(hackers.pub)주요 내용 요약
- 자바의 체크드 예외가 커뮤니티에서 널리 비판받는 기능임에도 타입 안전성 측면에서 뛰어난 장점 보유.
- Rust의
Result<T, E>나 Haskell의Either a b와 개념적으로 유사한 타입 안전성 메커니즘 제공. - 체크드 예외가 메서드 시그니처에 잠재적 실패 가능성을 명시적으로 표현하여 타입 시스템을 통한 오류 처리 강제.
체크드 예외의 장점
- 컴파일 타임에 예외 처리 여부 확인을 통한 타입 안전성 제공.
- 메서드 시그니처에
throws절로 예외 가능성을 명시하여 API 계약의 일부로 만듦. - 선언만 하면 자동으로 예외가 전파되는 편리한 메커니즘 제공.
- Rust와 달리 매 호출마다
?연산자 같은 추가 구문 불필요.
체크드 예외의 문제점
- 콜 체인에서 과도한 보일러플레이트 코드 발생.
- 자바 8 이후 도입된 람다와 스트림 API 등 함수형 프로그래밍과의 호환성 부족.
- 인터페이스에 새 예외 추가 시 호환성 깨짐으로 인한 API 진화 어려움.
- 예외를 무시하는 안티패턴 조장 가능성.
개선 제안
- 람다가 체크드 예외를 선언할 수 있도록 함수형 인터페이스 개선.
-
throws절에 제네릭 예외 타입 지원 추가. - 함수형 컨텍스트에서 체크드 예외를 더 잘 다룰 수 있는 API 확장.
-
Optional<T>및Stream<T>API와의 더 나은 통합.
다른 언어와의 비교
- Rust:
Result<T, E>와?연산자를 통한 명시적 오류 처리 메커니즘 제공. - Kotlin: 모든 예외를 언체크드로 만들었으나
runCatching과 같은 함수형 구조 제공. - Scala:
Try[T],Either[A, B]등의 모나딕 타입을 통한 함수형 오류 처리 지원.
결론
- 체크드 예외는 자바의 오해받은 혁신적 기능으로 재평가 필요.
- 완전히 포기하기보다 현대적 자바 기능과 잘 어울리도록 개선하는 것이 바람직함.
- 기존 패러다임 유지하면서 실용적 문제 해결 방향으로 발전 가능성 존재.
- 타입 안전성과 코드 간결성, 유연성 사이의 균형점 찾기 중요.
이미 십수년간 얘기했던 논쟁을 반복하는 느낌이 들었어요. Exception도 Type만큼의 가치가 있다는 주장같고, 저는 Type으로 충분하다는 대답을 해보고 싶습니다.