- 깨끗한 코드는 가독성이 있어야 하지만, 안정성도 높아야한다.
- 비즈니스 로직과 오류를 분리하라.

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

    1. if문을 쓰지 말고, 예외를 던지고 catch해라

  2. Try-Catch-Finally 문부터 작성하라 *Try-Resources-Catch

  3. 미확인 예외(unchecked)를 사용하라

    [ 미확인 예외(unchecked exception) ]
런타임 시 잘못 구현된 코드로 인해 발생하는 예외
컴파일 에러가 나지 않지만 적절한 예외처리가 없을 경우 프로그램이 강제 종료
컴파일 시 확인하지 않기 때문에 미확인 예외
RuntimeException에 포함된 예외들
    1. 미확인 예외를 처리하는 비용이 이득이 있나 고려해라
      1. 비용 → 상위>하위 의존성을 주고 처리할 것인가
    2. 확인된 예외 - OCP를 위반
      1. 상위에서 하위의 예외를 알아차리지 못한다.
      2. 하위에서 변경하면 상위까지 모두 바꿔야 한다. (캡슐화 깨진다.)

  4. 예외에 의미를 제공하라

    1. 오류 메세지에 정보를 담아 던진다.
    2. 정보 : 실패한 연산 이름, 실패 유형/ 로깅 기능도 쓴다.

  5. 호출자를 고려해 예외 클래스를 사용하라

    1. 오류를 분류하는 방법은 많다. 하지만
    2. 프로그래머의 초점은 “오류를 잡아내는 방법”이다.
      1. 오류를 잡아내는 방법은 동일한데, 지나치게 세분화한 오류 catch는 무의미할 수 있다.
      2. 세분화된 예외를 감싸서 간략하게 표현하자.

  6. 정상 흐름을 정의하라.

    1. 비즈니스 논리와 오류 처리가 잘 분리된 코드
    2. 특수 사례 패턴 : 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식
    MealExpenses expenses 
      = expenseReportDAO.getMeals(employee.getId());
m_total += expenses.getTotal()

    public class PerDiemMealExpenses implements MealExpenses {

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

  7. null을 반환하지 마라

    1. null 대신 예외를 던지거나 특수 사례 객체를 반환하라.
    2. Collections.emptyList()
    public List<Employee> getEmployee(){
   if (직원이 없다면) 
       return Collections.emptyList();
}

  8. null을 전달하지 마라

    1. NullPointerException의 발생 가능성
    2. 새로운 예외 유형을 만드는 방법
    public class MetricsCalculator{
   public double xProjection(Point p1, Point p2){
      if (p1 == null || p2 == null){
         throw InvalidArgumentException("오류 내용");
      }
      return (p2.x - p1.x) * 1.5;
   }
}

    c. assert문을 사용하는 방법 - AssertionError (다만 누군가 잡지 않으면 문제 해결X)

    public class MetricsCalculator{
   public double xProjection(Point p1, Point p2){
      assert p1 != null : "p1 shoud not be null";
      assert p2 != null : "p2 shoud not be null";
      return (p2.x - p1.x) * 1.5;
   }
}