범용 래퍼 예외를 피하는 것이 좋습니다 [RE#12]

내부 예외를 깔끔하게 정의된 예외 유형으로 감싸고 싶은 유혹에 빠진 적이 있다면 악마와 싸우는 것이 좋습니다. 예외가 스스로 발생하도록 하고 호출 스택을 자유롭게 높이 날아갑니다. 💸

이 문제를 자세히 설명하려면 아래의 가상DataProcessor 및 범용 예외 유형DataProcessingFailure을 고려하십시오.

class DataProcessingFailure extends Error {
  constructor(public innerError: Error) {
    super();
  }
}

class DataProcessor {
  process() {
    try {
      // Some processing
    } catch (err) {
      throw new DataProcessingFailure(err)
    }
  }
} 

여기서 process() 메서드는 DataProcessingFailure 예외가 있는 경우에만 발생합니다. 어떤 예외가 발생하든지(예: DivisionByZero ) process() 호출자는 DataProcessingFailure 인스턴스를 잡습니다. 따라서 DataProcessingFailure는 래퍼 예외입니다.

래퍼 예외에 대해 조언하는 이유는 상위 수준 컨트롤러에서 볼 수 있는 다운스트림 시스템에 적용하는 동작의 변경 때문입니다. 예를 들어 자체가 도메인 모델의 복잡한 부분이라는 잘 정의된 예외를 마스킹할 수 있습니다. 또 다른 예는 래퍼가 네트워크 관련 예외를 마스킹할 수 있는 경우입니다. 대부분은 재시도만으로 해결되지만 상위 수준의 호출 스택에 있는 일부 호출자가 이러한 예외를 있는 그대로 catch할 수 있습니다.

모든 것을 종합하면 논리적으로 다양한 구성 요소/구현의 풋프린트/부작용을 최소화하는 것을 선호하므로 원치 않는 커플링/특수 처리를 피할 수 있습니다.


정기적인 만남에 대해
직업적인 문제와 일상적인 만남을 다소 정기적으로 기록하기로 결정했습니다. 그것들 모두가 똑같이 중요하고/고유하고/복잡한 것은 아니지만 실제로는 실용적이고 현실적이며 물론 텍스트적으로 최소한의 것입니다.