DAY 13

🔖 오늘 읽은 범위 : 7. 오류처리 (130~137p)

🤓 책에서 기억하고 싶은 내용

오류 코드보다 예외를 사용하라

• 예외처리가 아닌 오류 코드반환 방식을 쓰면 함수를 호출한 즉시 오류를 확인해야한다
• 오류가 발생하면 예외를 던져라 → 호출자 코드가 깔끔해지고 논리와 오류처리가 뒤섞이지 않음

  public class DeviceController {
      ...
      public void sendShutDown() {
          try {
              tryToShutDown();
          } catch (DeviceShutDownError e) {
              logger.log(e);
          }
      }
      private void tryToShutDown() throws DeviceShutDownError {
          DeviceHandle handle = getHandle(DEV1);
          DeviceRecord record = retrieveDeviceRecord(handle);
          pauseDevice(handle);
          clearDeviceWorkQueue(handle);
          closeDevice(handle);
      }
      private DeviceHandle getHandle(DeviceID id) { ...
              throw new DeviceShutDownError("Invalid handle for: " + id.toString());
              ...
          }
          ...
  }

Try-Catch-Finally 문부터 작성하라

• try 블록은 트랜잭션과 비슷
• try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지
• 파일이 없으면 예외를 던지는지 알아보는 단위 테스트

  @Test(expected = StorageException.class)
  public void retrieveSectionShouldThrowOnInvalidFileName() {
  	sectionStore.retrieveSection("invalid - file"); 
  }

  public List<RecordedGrip> retrieveSection(String sectionName) { 
  	// 실제로 구현할 때까지 비어 있는 더미를 반환한다.
  	return new ArrayList<RecordedGrip>();
  }

  예외를 던지지 않으므로 단위 테스트 실패 → 잘못된 파일 접근으로 변경

  public List < RecordedGrip > retrieveSection(String sectionName) {
      try {
          FileInputStream stream = new FileInputStream(sectionName)
      } catch (Exception e) {
          throw new StorageException("retrieval error", e);
      }
      return new ArrayList < RecordedGrip > ();
  }

  Refactoring: catch 예외 유형 범위를 좁힌다 Exception → FileNotFoundException

  public List < RecordedGrip > retrieveSection(String sectionName) {
      try {
          FileInputStream stream = new FileInputStream(sectionName);
          stream.close();
      } catch (FileNotFoundException e) {
          throw new StorageException("retrieval error", e);
      }
      return new ArrayList < RecordedGrip > ();
  }

  나머지 필요한 논리를 TDD로 추가한다
  

1. 강제로 예외를 일으키는 테스트 케이스를 작성
2. 테스트를 통과하게 코드를 작성
3. try블록의 트랙잭션 범위부터 구현하게되므로 트랜잭션 본질을 유지하고 로직 추가에 용이하다

미확인 예외를 사용하라

• 확인된 예외는 OpenClosedPrinciple 을 위반한다
  • 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부 전부 고쳐야함
  • throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨짐
• 확인된 예외도 유용하긴 하지만 의존성 비용을 줄이는게 더 중요하므로 미확인(unchecked) 예외를 사용해도 된다

예외에 의미를 제공하라

• 오류 메시지에 정보를 담아 예외와 함께 던진다
• 실패한 연산 이름과 실패 유형도 언급
• APP 에서 로깅기능을 사용할때 충분히 정보를 활용하도록 catch 블록에서 오류 출력

호출자를 고려해 예외 클래스를 정의하라

• 가장 중요한 관심사는 오류를 잡아내는 방법
• wrapper 클래스 활용하여 예외 처리를 간결하게

  LocalPort port = new LocalPort(12);
  try {
      port.open();
  } catch (PortDeviceFailure e) {
      reportError(e);
      logger.log(e.getMessage(), e);
  } finally {
      ...
  }

  public class LocalPort {
      private ACMEPort innerPort;
      public LocalPort(int portNumber) {
          innerPort = new ACMEPort(portNumber);
      }
      public void open() {
              try {
                  innerPort.open();
              } catch (DeviceResponseException e) {
                  throw new PortDeviceFailure(e);
              } catch (ATM1212UnlockedException e) {
                  throw new PortDeviceFailure(e);
              } catch (GMXError e) {
                  throw new PortDeviceFailure(e);
              }
          }
          ...
  }

  • 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어듬
  • 나중에 다른 라이브러리로 갈아타도 비용이 적음
  • 외부 API 호출 대신 테스트 코드를 넣어서 테스트 하기도 용이
  • 특정 업체가 API를 설계한 방식에 발목 잡히지 않음

🤔 떠오르는 생각

• 학부생 때는 에러처리가 귀찮다고만 느껴졌는데 이렇게 전, 후의 코드를 놓고 비교하니 에러 처리 역시 Clean해야 함을 한 눈에 알 수 있었다

🔎 질문

📝 소감 3줄 요약

• 오류보다 (미확인)예외를 활용하라
• 예외를 일으키는 try-catch 먼저 완성 시키고 로직을 추가하자
• Error wrapper class 를 활용해서 의존성을 줄이자