[클린코드(CleanCode)] 7장 오류 처리

개요

깨끗한 코드를 다루는 책에서 오류 처리를 다루는 장이 있어 이상하게 여길 수 있지만

오류 처리는 프로그램에 반드시 필요한 요소 중 하나일 뿐이다.

 

깨끗한 코드와 오류 처리는 확실히 연관성 있다.

상당수 코드 기반은 전적으로 오류 처리 코드에 좌우된다.

오류 처리 코드 때문에 길제 코드가 하는 일을 파악하기 불가능한 일이 발생하고

프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.

---

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

public class DeviceController {
	...
	DeviceHandle handle = getHandle(DEV1);
	if (handle != DeviceHandle.INVALID) {
		retrieveDeviceRecord(handle);
		if (record.getStatus() != DEVICE_SUSPENDED) {
			closeDevice(handle);
		} else {
			logger.log("Device suspended. Unable to shut down");
		}
	} else {
		logger.log("Invalid handle");
	}
	...
}

위의 코드의 경우 호출자 코드가 복잡해진다.

함수를 호출한 즉시 오류를 확인해야 하기 때문이다.

그래서 오류가 발생하면 예외를 던지는 편이 낫다.

그러면 호출자 코드가 더 깔끔해진다.

 

public class DeviceController {
	...
	public void sendShutDown() {
		try {
			tryToShutDown();
		}
		catch (DeviceShutDownError e) {
			logger.log(e);
		}
	}

	private void tryToShutDown() {
		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 블록은 프로그램 상태로 일관성 있게 유지해야 한다.

그러므로 예외가 발생할 코드를 짤 때는 try-catch-finally 문으로 시작하는 편이 낫다.

그러면 try블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.

 

파일이 없으면 예외를 던지는지 알아보는 단위 테스트

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

 

단위 테스트에 맞춰 구현한 코드

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-catch 구조로 범위를 정의했으므로 TDD를 사용해 필요한 나머지 논리를 추가한다. 나머지 논리는 FileInputStream을 생성하는 코드와 close 호출문 사이에 넣으며 오류나 예외가 전혀 발생하지 않는다고 가정한다.

 

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

---

미확인 예외를 사용하라

체크 예외(Checked Exception)는 OCP를 위반한다.

메서드에서 체크 예외를 던졌는데 catch 블록이 세 단계 위에 있다면 그 사이 메서드 모두가 선언부에 해당 예외를 정의해야 한다.

즉, 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다.

모듈과 관련된 코드가 전혀 바뀌지 않았더라도 모듈을 다시 빌드 한 다음 배포해야 한다.

 

대규모 시스템에서 호출이 일어나는 방식을 상상해 보자.

최상위 함수가 아래 함수를 호출하면 그 아래 함수는 다시 그 아래 함수를 호출한다.

단계를 내려갈수록 호출하는 함수는 늘어난다.

이제 최하위 함수를 변경해 새로운 오류를 던진다고 가정하자.

체크 예외를 던진다면 함수는 선언부에 throws 절을 추가해야 한다.

그러면 변경한 함수를 호출하는 함수 모두가 catch 블록에서 새로운 예외를 처리하거나 선언부에 throw 절을 추가해야 한다.

결과적으로 최하위 단계에서 최상위 단계까지 연쇄적인 수정이 일어난다.

이는 throws 경로에 위치하는 모든 함수가 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다.

 

때로는 체크 예외도 유용하다.

아주 중요한 라이브러리를 작성한다면 모든 예외를 잡아야 한다.

하지만 애플리케이션은 의존성이라는 비용이 이익보다 크다.

---

예외에 의미를 제공하라

예외를 던질 때는 전후 상황을 충분히 덧붙인다.

그러면 오류가 발생한 원인과 위치를 찾기가 쉬워진다.

 

자바는 모든 예외에 호출 스택을 제공한다.

하지만 실패한 코드의 의도를 파악하려면 호출 스택만으로 부족하다.

 

오류 메시지에 정보를 담아 예외와 함께 던진다.

실패한 연산 이름과 실패 유형도 언급한다.

애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다.

---

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

오류를 분류하는 방법은 수없이 많다.

• 오류가 발생한 위치로 분류한다
• 오류가 발생한 컴포넌트로 분류한다.
• 오류의 유형으로도 분류
  • 디바이스 실패
  • 네트워크 실패
  • 프로그래밍 실패 등

하지만 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.

 

다음은 오류를 형편없이 분류한 사례다.

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");
} finally {
    ...
}

위 경우 예외에 대응하는 방식이 예외 유형과 무관하게 거의 동일하다. 

그래서 코드를 간결하게 고치기가 쉽다.

호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 반환하면 된다.

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

Public class LoaclPort {
    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);
      }
    }
    ...
}

LocalPort 클래스처럼 ACMEPort를 감싸는 클래스는 매우 유용하다.

실제로 외부 API를 사용할 때는 래퍼 클래스로 감싸는 기법이 최선이다.

• 외부 라이브러리와 프로그램 사이의 의존성이 줄어든다.
• 다른 라이브러리로 갈아타더라도 비용이 적다.
• 테스트 코드를 통해 프로그램을 테스트하기 쉬워진다.
• 외부 API의 설계 방식에 발목 잡히지 않는다.

예외 클래스가 하나만 있어도 충분한 코드가 많다.

예외 클래스에 포함된 정보로 오류를 구분해도 괜찮은 경우가 그렇다.

한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다.

---

정상 흐름을 정의하라

중단이 적합하지 않을 때도 있다.

 

다음 코드는 비용 청구 애플리케이션에서 총계를 계산하는 허술한 코드다.

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

 

특수한 상황을 처리할 필요가 없다면 다음 코드처럼 간결해진다.

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

 

ExpenseReportDAO를 고쳐 언제나 MealExpense 객체를 반환하게 한다.
청구한 식비가 없다면 일일 기본 식비를 반환하는 MealExpense 객체를 반환한다.

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

 

이런 사례를 "특수 사례 패턴"이라 부른다.

클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다.

그러면 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.

---

null을 반환하지 마라

오류를 처리하려다가 오히려 오류를 유발하는 행위가 바로 null을 반환하는 습관이다.

public void registerItem(Item item) {
    if (item != null) {
        ItemRegistry registry = persistentStore.getItemRegistry();
        if (registry != null) {
            Item existing = registry.getItem(item.getId());
            if (existing.getBillingPeriod().hasRetailOwner()) {
                existing.register(item);
            }
        }
    }
}

null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다. 

누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.

 

그리고 persistentStore의 null 확인이 빠졌다는 사실을 눈치챘는가?

persistentStore가 null이라면 실행 시 NPE(NullPointerException)가 발생했을 것이다.
위쪽 어디선가 NPE를 잡을지도 모르고 아닐지도 모르지만 결국 어느 쪽이든 나쁘다.

List<Employee> employees = getEmployees();
for (Employees e : employees) {
    totalPay += e.getPay();
}

이런 식으로 null을 반환하지 않고 코드를 짠다면 훨씬 깔끔해진다.

---

null을 전달하지 마라

메서드에서 null을 반환하는 방식도 나쁘지만 메서드로 null을 전달하는 방식은 더 나쁘다. 

정상적인 인수로 null을 기대하는 API가 아니라면 메서드로 null을 전달하는 코드는 최대한 피해야 한다.

 

다음은 두 지점 사이의 거리를 계산하는 간단한 메서드다.

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        return (p2.x - p1.x) * 1.5;
    }
}

 

다음과 같이 누군가 인수로 null을 전달한다면 NPE가 발생할 것이다.

calculator.xProjection(null, new Point(12, 13));

 

다음과 같이 새로운 예외 유형을 만들어 던지면 전달받은 null 문제를 해결할 수 있다.

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        if (p1 == null || p2 == null) {
            throw InvalidArgumentException("Invalid argument for MetricsCalculator.xProjection");
        }
        return (p2.x - p1.x) * 1.5;
    }
}

하지만 위 코드는 InvalidArgumentException을 잡아내는 처리기가 필요하다.

 

또 다른 대안으로 asssert 문을 사용하는 방법도 있다.

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

 

문서화가 잘 되어 코드 읽기는 편하지만 문제를 해결하지는 못한다. 

누군가 null을 전달하면 여전히 실행 오류가 발생한다.
 
대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없기에 null을 넘기지 못하도록 금지하는 것이 좋다.

즉, 인수로 null이 넘어오면 코드에 문제가 있다는 의미이다. 

null을 넘기지 못하도록 한다면 부주의한 실수를 저지를 확률이 작아진다.

---

결론

깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 

이 둘은 상충하는 목표가 아니므로 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다. 

오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지 보수성도 크게 높아진다.

---

글쓴이의 생각

대학교 과제할 때 오류 처리하는 코드를 많이 짜도록 시켰다.

그때는 오류 처리해야 하는 항목들을 많이 줘서 오류 처리 코드만 100줄 넘어갔던 것 같다.

그러나 일을 하면서 버그가 주는 심각성을 많이 느꼈고

오류 처리, 예외사항 처리를 할게 산떠미로 늘어났다.

그러면서 코드가 많이 지저분 해진 것 같다.

특히 null을 이용한 오류 처리 방식을 자주 사용했어서 문제도 많이 생겼었다.

앞으로는 코드의 가독성과 안정성을 높일 겸 위의 내용들을 참고해서 코드를 짜야겠다.