[Clean Code]오류 처리, 경계

2 분 소요

Clean Code

오류 처리

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

오류를 코드로 처리하면 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인해야 하기 때문이다.
오류가 발생하면 예외를 던지는 편이 낫다. 호출자 코드가 더 깔끔해진다.
```
  public void sendShutDown(){
      try{
          tryToShutDown();
      }catch(DeviceShutDownError e){
          logger.log(e);
      }
  }
```
예외를 던지고 코드를 분리함으로써 각 개념을 독립적으로 살펴보고 이해할 수 있다.

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

try-catch-finally 문에서 try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다.

try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.

  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>();
  }

먼저 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 하는 코드를 작성하는 방법을 권장한다. -> 그러면 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.

미확인 예외를 사용하라

확인된 예외는 OCP(Open Closed Principle)를 위반한다.
메소드에서 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메소드 모두가 예외를 정의해야 한다.
아주 중요한 라이브러리를 작성할 때를 제외하면 확인된 예외는 비용소모가 더 크다.

예외에 의미를 제공하라.

예외를 던질 때는 오류가 발생한 원인과 위치를 찾기 쉽도록 전후 상황을 충분히 덧붙인다.
오류 메시지에 정보를 담아 예외와 함께 던진다.

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

오류가 발생한 컴포넌트로 분류한다. 유형으로도 분류가 가능하다.
호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 반환하게 한다.
외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.

정상 흐름을 정의하라

예외가 발생하는 특수상황이 없도록 만들면 코드가 훨씬 더 간결해진다.

  try{
      MealExpenses expenses = expensesReportDAO.getMeals(employee.getID());
      m_total += expenses.getTotal();
  } catch(MealExpensesNotFound e){
      m_total += getMealPerDiem();
  }

위와같은 특수한 예외상황 자체가 안나오도록 만들어준다.

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

클래스나 객체가 예외적인 상황을 캡슐화해서 상황을 처리하므로 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다. 이를 특수 사례 패턴이라 부른다.

null을 반환하지 마라

null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.
null을 반환하는 대신 예외를 던지거나 특수 사례 객체를 반환한다.

자바에는 Collections.empltyList()가 있어 미리 정의된 읽기 전용 리스트를 반환한다.

 public List<Employee> getEmployees(){
     if( ... )
         return Collections.emptyList();
 }

null을 전달하지 마라

null을 인수 값으로 전달하는 방식도 피해야 한다.
인수 값으로 null을 전달하면 결국 메소드위치에서 null을 검사하는 처리가 필요하다.

경계

외부 코드 사용하기

예) java.util.map
Map은 굉장히 다양한 인터페이스로 수많은 기능을 제공한다.
Map이 제공하는 기능성과 유연성은 확실히 유용하지만 그만큼 위험도 크다.

경계 인터페이스인 Map을 Class 안으로 숨기면, Map 인터페이스가 변하더라도 나머지 프로그램에는 영향을 미치지 않는다.

  public class Sensors{
      private Map sensors = new HashMap();

      public Sensor getById(String id){
          return (Sensor) sensors.get(id);
      }
  }

Map과 같은 경계 인터페이스를 이용할 때는 이를 이용하는 클래스나 클래스 계열 밖으로 노출되지 않도록 주의한다.

경계 살피고 익히기

우리쪽 코드를 작성해 외부 코드를 호출하는 대신 먼저 간단한 테스트 케이스를 작성해 외부 코드를 익히자.

log4j 익히기

학습 테스트: 프로그램에서 사용하려는 방식대로 외부 API를 호출
실제 코드와 동일한 방식으로 인터페이스를 사용하는 테스트 케이스가 필요하다. 이런 경계 테스트가 있다면 패키지의 새 버전으로 이전하기 쉬워진다.

깨끗한 경계

경계에 위치하는 코드는 깔끔히 분리한다.
또한 기대치를 정의하는 테스트 케이스도 작성한다.
외부 패키지를 호출하는 코드를 가능한 줄여 경계를 관리하자.
Map에서 봤듯이, 새로운 클래스로 경계를 감싸거나 아니면 ADAPTER 패턴을 사용해 우리가 원하는 인터페이스를 패키지가 제공하는 인터페이스로 변환하자

Twitter Facebook LinkedIn

Jinnie