[클린 코드] 7장. 오류 처리

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

• 오류가 발생하면 예외를 던지는 편이 더 낫다. 그러면 호출자 코드가 더 깔끔해진다.
  논리가 오류 처리 코드와 뒤섞이지 않으니까.

// good
public class DeviceController {
  ...
  
  public void sendShoutDown() {
    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-catch-finally 문에서 try 블록에 들어가는 코드를 실행하면 어느 시점이든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다.
  그러므로 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다.
  그러면 try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.
• 먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법을 권장한다.
  그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.

// good
// 파일이 없으면 예외를 던지는지 알아보는 단위 테스트
@Test(expected = StorageException.class)
public void retrieveSectionShouldThrowOnInvalidFileName() {
  sectionStore.retriveSection("invalid - file");
}

// 코드 
public List<RecordGrip> retrieveSection(String sectionName) {
  try {
    FileInputStream stream = new FileIputStream(sectionName);
    stream.close();
  } catch (FileNotFoundException e) {
    throw new StorageException("retrieve error", e);
  }
  return new ArrayList<RecordGrip>();
}

미확인 예외를 사용하라

• 확인된 예외는 컴파일 단계에서 확인되며 예외처리를 구현하지 않으면 컴파일 에러가 발생하게 된다.
  하지만 지금은 안정적인 소프트웨어를 제작하는 요소로 확인된 예외가 반드시 필요하지는 않다는 사실이 분명해졌다.
• 확인된 예외는 개방-폐쇄 원칙을 위반하므로 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다.
• 미확인된 예외는 실행 단계에서 확인되며 명시적인 처리를 강제하지 않는 예외이다.
• 아주 중요한 라이브러리를 작성한다면 모든 예외를 잡아야 한다.
  하지만 일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.

예외에 의미를 제공하라

• 예외를 던질 때는 전후 상황을 충분히 덧붙인다.
• 오류 메시지에 정보를 담아 예외와 함께 던진다.
• 실패한 연산 이름과 실패 유형도 언급한다.
• 애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다.

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

• 예외에 대응하는 방식이 예외 유형과 무관하게 거의 동일할 경우
  호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 반환하면 된다.
• 외부 API를 사용할 때는 감싸기 기법이 최선이다.
  외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.

// bad
ACMEPort port = new ACMEPort(12);

try {
  port.open();
} catch (DeviceResponseException e) {
  reportPortError(e);
  logger.log("Device response exception", e);
} catch (ATM1212UnlockedException e) {
  reportPortError(e);
  logger.log("Unlock exception", e);
} catch (GMXError e) {
  reportPortError(e);
  logger.log("Device response exception", e);
} finally {
  ...
}

// good
// LocalPort 클래스는 단순히 ACMEPort 클래스가 던지는 예외를 잡아 변환하는 감싸기 클래스
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);
    } 
  }
  ...
}

정상 흐름을 정의하라

• 비즈니스 논리와 오류 처리가 잘 분리된 코드를 작성하다보면
  오류 감지가 프로그램 언저리로 밀려나 예외가 논리를 따라가기 어렵게 만든다.
• 이 때 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 특수 사례 패턴 방식을 사용할 수 있다.
  그러면 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.

// bad
// 식비를 비용으로 청구했다면 직원이 청구한 식비를 총계에 더한다.
// 식비를 비용으로 청구하지 않았다면 기본 식비를 총계에 더한다.
try {
  MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
  m_total += expenses.getTotal();
} catch(MealExpensesNotFound e) {
  m_total += getMealPerDiem();
}

// good
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();

public class PerDiemMealExpenses implements MealExpenses {
  public int getTotal() {
    // 기본값으로 일일 기본 식비를 반환한다.
  }
}

null을 반환하지 마라

• null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다.
  누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.
• 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다.
• 사용하려면 외부 API가 null을 반환한다면 감싸기 메서드로 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다.

// bad
List<Employee> employees = getEmployees();
if (employee != null) {
  for(Employee e : employees) {
    totalPay += e.getPay();
  }
}

// good
// 특수 사례 패턴 방식
List<Employee> employees = getEmployees();
for(Employee e : employees) {
  totalPay += e.getPay();
}

public List<Employee> getEmployees() {
  if ( .. 직원이 없다면 .. )
    return Collections.emptyList();
}

null을 전달하지 마라

• 정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피한다.
• 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다.
  그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다.