엘레강트 오브젝트 [4장 - (2)]

⌗ 엘레강트 오브젝트 책을 리뷰해보도록 하겠습니다.

책의 내용은 다양한 언어로 되어있지만, 저는 예시 코드로 Typescript 를 사용해 제 사족을 조금씩 붙일 예정입니다.

 

체크 예외만 던지세요

 

이 책은 역시나 java 를 기준으로 작성되어 있기 때문에, 체크 예외와 언체크 예외에 대해 얘기하고 있습니다.

간단하게 이에 대해 먼저 보자면 체크 예외는 복구 가능한 예외들이기때문에 에러 핸들링을 꼭 해줘야하고, 코드상에서 이를 해주지 않을
경우 컴파일 에러가 발생합니다.

언체크 예외는 에러 핸들링을 강제하지 않는 예외들이고, 프로그램에 오류가 있을 때 발생하도록 의도되었습니다.

 

결국 이 부분에서 저자가 얘기하는 바는 체크 예외는 반드시 잡아야하기 때문에, 이런 예외는 가시적이고 해로우면서 안전하지 않다는 사실을 전달해준다는 점입니다.

typescript 에선 uncaughtException 이라는게 있긴 하지만, 위에서 얘기하는 체크 예외 언체크 예외와는 조금 다른 것 같습니다.
java 에선 체크 예외를 핸들링하거나 상위 레벨로 throw 하지 않으면 언체크 예외와는 달리 자동으로 상위 전파가 되지 않는 것 같은데 typescript(javascript 동일)에선 발생한 에러들이 핸들링 될 곳을 찾아 자동으로 상위를 찾아가니 이것도 좀 다르네요.

 

이후 내용은 에러 핸들링을 어떻게 하자 정도가 될텐데 이를 typescript 에 적용해 이어서 보도록 하겠습니다.

 

- 꼭 필요한 경우가 아니라면 예외를 잡지 마세요

 

가능하면 예외를 더 높은 레벨로 전파하세요.

이상적인 설계에서는 어플리케이션의 각 진입점 별로 오직 하나의 catch 문만 존재해야 합니다.

 

public length(file: File): number {
  try {
    return content(file).length();
  } catch (e) {
    return 0;
  }
}

 

위처럼 작업된 length 메서드가 있다면, 아주 안전한 메서드입니다.

파일 시스템에 어떤 일이 발생해도 메서드는 종료될 일 없이 항상 number 를 반환하고 어플리케이션은 계속 실행됩니다.

이전 포스팅들에서 봤던 안전하게 실패하기의 전헝적인 예시로 볼 수 있죠.

 

결과적으로 파일이 정상적이지 않더라도 어떠한 경고도 없이 무시되어버립니다. 이 책의 저자는 빠르게 실패하기를 강력히 권장하므로,

위 메서드는 return 0 이 아닌 예외를 던지도록 되어야 합니다.

물론 전 이전에도 말한것처럼 빠르게 실패가기가 일반적으로 맞다고 보지만 트레이드오프로 안전하게 실패하기의 방법을 선택할 때가 있습니다. 이후 나오는 내용들까지 보면서 개발자가 스스로 선택하면 되겠습니다.

 

- 항상 예외를 체이닝하세요

 

public length(file: File): number {
  try {
    return content(file).length();
  } catch (e) {
    throw new Error(e);
  }
}

 

예외를 잡은 즉시 예외를 던집니다. 이러한 것을 예외 체이닝이라고 합니다.

사실 typescript 에선 위처럼 던지면 괜히 예외이름만 하나가 더 붙으니 그냥 throw e 를 하는게 가장 나을 수 있습니다.

핵심은 문제를 발생시켰던 낮은 수준의 근본 원인을 높은 수준으로 이동시켰다는 것입니다.

 

항상 예외를 체이닝하고 절대로 원래 예외를 무시하지 마세요.

여기서 추가로 덧붙일만한 얘기는 가능하면 많은 정보를 얻을 수 있도록 예외의 정보를 충분히 전달하라는 것입니다.

 

- 단 한번만 복구하세요

 

예외 후 복구는 빠르게 실패하기와 안전하게 실패하기 사이의 충돌을 다른 각도에서 바라본 것 뿐입니다.

저자가 얘기하는 빠르게 실패하기 에선 복구라는 개념 자체가 사실 존재하지 않습니다. 예외 후 복구는 안티패턴 입니다.

 

하지만 무조건 예외를 잡아서는 안된다기보단, 딱 한번만 복구해야 하고 가장 적절한 지점은 진입점일 것입니다.

Node.JS 로 작성한 어플리케이션 혹은 예를 들어 Express 로 작성한 웹서버라면, 최상위 진입점에서 한번만 복구하는 것이 좋습니다.

아무것도 하지 않는다면 예외가 발생했을 때 그냥 어플리케이션이 죽어버릴 것이기에, 이는 적절한 상황이 아닐 것이고 런타임 환경이 제공하는 에러 메세지또한 충분치 않습니다. 이때만 복구를 하세요.

 

여기까지가 제가 정리한 엘레강트 오브젝트의 내용입니다. 저자가 OOP 에 대해 주장하는 바는 너무도 확고해서 원래 갖고 있던 생각과 충돌하는 부분들이 있긴 하지만, 좋은 내용도 많았습니다.