8P by hongminhee | ★ favorite | 댓글 1개

주요 내용 요약

  • 자바의 체크드 예외가 커뮤니티에서 널리 비판받는 기능임에도 타입 안전성 측면에서 뛰어난 장점 보유.
  • 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] 등의 모나딕 타입을 통한 함수형 오류 처리 지원.

결론

  • 체크드 예외는 자바의 오해받은 혁신적 기능으로 재평가 필요.
  • 완전히 포기하기보다 현대적 자바 기능과 잘 어울리도록 개선하는 것이 바람직함.
  • 기존 패러다임 유지하면서 실용적 문제 해결 방향으로 발전 가능성 존재.
  • 타입 안전성과 코드 간결성, 유연성 사이의 균형점 찾기 중요.
GeekNews Weekly에 포함된 글입니다. 에디터 코멘트 보기

댓글과 토론

이미 십수년간 얘기했던 논쟁을 반복하는 느낌이 들었어요. Exception도 Type만큼의 가치가 있다는 주장같고, 저는 Type으로 충분하다는 대답을 해보고 싶습니다.