[클린코드] 오류 처리

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

오류처리는 중요하다. 하지만 오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라고 부르기 어렵다.

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

(3장 함수에도 나왔다. 오류 코드보다 예외를 사용하라! → 오류 코드 대신 예외(ex. try/catch)를 사용하면 오류 처리 코드가 원래 코드에서 분리되어 코드가 깔끔해진다.)

[클린코드] 함수

 

논리가 오류 처리 코드와 뒤섞이지 않는다. (코드품질 굳)

 

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

예외가 발생할 코드를 짜는 경우엔 try/catch문으로 시작하는게 좋다.

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

 

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

checked 예외는 반드시 예외 처리를 해줘야 한다.

 

아래처럼 a -> b, b -> c를 부르는데 c가 checked 예외를 던지면 a, b 전부 예외를 잡기 위해 throws를 붙혀줘야 한다.

public void a() throws FileNotFoundException { // 또 예외를 잡고
    b();
}
 
private void b() throws FileNotFoundException { // 또 예외를 잡고
    c();
}
 
private void c() throws FileNotFoundException {
    FileInputStream stream = new FileInputStream("fileName");
}

처음부터 붙였으면 그나마 괜찮은데 추후에 소스 수정이 일어나서 c에 다른 checked 예외를 추가한다면? a, b에 또 예외 처리를 추가해야 한다. 이는 OCP를 위반한다.

일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.

 

예외에 의미를 제공하라

오류 메시지에 정보를 담아 예외와 함께 던진다. 오류가 발생한 원인과 위치를 찾기가 쉬워진다. (짐작도 가능)

 

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

1. 1번(p.135) 코드는 외부 라이브러리를 호출하고 모든 예외를 호출자가 잡아내고 있다.
2. 호출 라이브러리 API를 감싸 한가지 예외 유형을 반환하는 방식으로 단순화 → 이 경우는 예외에 대응하는 방식이 예외 유형과 무관하게 거의 동일함

 

외부 API를 감싸면 아래와 같은 장점이 있다.

• 에러 처리가 간결해짐
• 외부 라이브러리와 프로그램 사이의 의존성이 크게 줄어듦 → 다른 라이브러리로 갈아타도 비용이 적음
• 프로그램 테스트가 쉬워짐
• 외부 API 설계 방식에 의존하지 않아도 됨

 

정상 흐름을 정의하라

예외가 논리를 따라가기 어렵게 만든다. (p.138)

→ 특수 사례 패턴으로 특수 사례를 처리

→ 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하므로 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어진다.

 

null을 반환하지 마라

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

 

하지만 실상은 null 확인이 너무 많아 문제다. 메서드에서 null을 반환하고픈 유혹이 든다면 그 대신 예외를 던지거나 특수 사례 객체를 반환한다.

 

많은 경우에 특수 사례 객체가 손쉬운 해결책이다.

ex) getEmployees에서 null 반환 대신 빈 리스트 반환

// bad
List<Employee> employees = getEmployees();
if(employees != 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();
}

코드가 깔끔해질뿐더러 NPE 발생 가능성도 적다.

null을 전달하지 마라

얘가 더 나쁘다.

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

• 예외를 던지거나 assert 문을 사용할 수는 있다.
• 하지만 애초에 null을 전달하는 경우는 금지하는 것이 바람직하다.