[Item70] Checked Exception 금지

Item70에서는 복구할 수 있는 예외는 checked-exception, 프로그래밍 오류는 unchecked-exception을 사용하라 말한다

옛날 글이지만 지금 봐도 좋은 checked-exception 관련된 글을 찾았다

C# Lead Architect가 checked-exception 개념을 왜 C#에서 빼버렸는지에 대한 인터뷰 글이다

 

artima - The Trouble with Checked Exceptions

 

checked-exception 의도 자체는 API 설계자가 생각하기에 사용자가 복구할 수 있는 상황일 때 처리를 강제하기 위함이다

인터뷰에서 패널과 인터뷰이는 checked-exception 개념 자체는 훌륭하나 자바에서 올바르게 쓰이고 있지 않다고 말했다

핵심적인 문제 두 가지는 버저닝과 확장성 (versioning & scalability) 때문이다

 

버저닝 문제란 JDK 1.1에서 제공하던 API는 AException이라는 1개의 checked-exception을 던졌다면

JDK 1.2에서는 기존에 제공하던 API에 기능을 추가하기 위해 수정을 했는데 의도치 않게

AException과 다른 1개 이상의 checked-exception을 던져야 한다면 하위 호환성이 깨지게 된다

checked-exception이 유연하지 않고 후 처리를 강제하니 나타나는 폐해다

이렇게 되면 API 내부적으로 꼼수를 써야하는데 Runtime으로 바꿔 던지거나 try-catch로 잡고 아무것도 안 하는 것이다

결국 좋은 의도를 가졌더라도 기능 추가에 발목을 잡게하는 요소가 되고 코드가 더러워지는건 덤이다

 

C# 개발 그룹에서는 checked-exception을 자바처럼 난리 부르스 치는 방식이 아니라 조용히 처리하는 걸 원했다고 한다

Calendar App을 만드는 초보 개발자의 예시를 들으며 뭐든 동작하는 가장 단순한 방식으로 작성하라고 주장한다

규모가 작은 프로젝트에서 checked-exception을 적절히 사용하면 안전하고 품질 좋은 서비스를 만들 수 있겠으나

모두가 알다시피 현실이란 것이 그리 달콤하지가 않다 

 

단순한 예를 들어 checked-exception을 뿌리는 외부 API 몇 개를 조합해 하나의 메서드를 작성한다고 하면

완성된 후 해당 메서드가 뿌리는 checked-exception의 수가 기하급수적으로 늘어날 수 있다

이런 메서드의 예외처리는 AException, BException, CException ... 등

광적으로 개별 처리에 집착하거나 아래와 같은 throws Exception + try-catch 처리로 귀결된다

try {
  // do something
} catch (Exception e) {
  // do nothing or logging
}

 

그냥 난 모르겠다 하고 콜스택을 따라 다 집어던져도 되긴 하지만, exception-bubbling을 그리 권할만 하진 않으니 위처럼 처리한다

1. try-catch로 감싸 아무것도 안 하고 그냥 무시하거나
2. 그것보다 조금 낫다면 로그나 남기거나
3. 처리할 건 딱히 없지만 알리기는 해야 하니 Runtime 계열 예외로 감싸서 다시 던진다

 

자바에서 checked-exception이 없어지는 그날까지는 열심히 예외 처리를 해주도록 하자 

자바가 영향을 준 언어라 할 수 있는 C#, ruby도 진작 checked-exception 개념은 버렸고

거의 자바 대체재라고 할 수 있는 코틀린은 위와 같은 이유들로 checked-exception 자체를 없애버렸다

자바도 어찌됐든 흐름을 따라가려고 하니 머지않아 checked-exception을 RuntimeException 계열로 바꾸지 않을까?