- 깨끗한 코드와 오류 처리는 확실히 연관성이 있다.
- 여기저기 흩어진 오류 처리 코드 때문에 실제 로직을 파악하기 거의 불가능해지게 된다는 의미다.
- 이는 깨끗한 코드라 부르기 어렵다.
오류 코드보다 예외를 사용하라
- 오류코드를 사용하면 로직과 오류처리가 뒤섞인다.
- 오류가 발생하면 예외를 던지는 편이 낫다. 호출자 코드가 더 깔끔해진다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
//나쁜코드
public class DeviceController {
public void sendShutDown() {
DeviceHandle handle = getHandle(DEV1);
if(handle != DeviceHandle.INVALID) {
retrieveDeviceRecord(handle);
if(record.getStatus() != DEVICE_SUSPENDED) {
pauseDevice(handle);
clearDeviceWorkQueue(handle);
closeDevice(handle);
} else {
logger.log("Device suspended. Unable to shut down");
}
} else {
logger.log("Invalid handle for: " + DEV1.toString());
}
}
}
//개선 - 오류처리하는 하나의 함수를 로직을 수행하는 함수 + 예외 처리한 함수로 분리
public class DeviceController {
public void sendShutDown() {
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);
}
}
Try-Catch-Finally 문부터 작성하라
- try 블록은 트랜잭션과 비슷하다.
- 무슨 일이 생기든 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
- 그러므로 예외가 발생할 코드를 짤 땐 try-catch-finally 문부터 시작하는 편이 낫다.
- try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워진다.
- 강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법이 좋다.
- 자연스럽게 try 블록의 트랜잭션 범위부터 구현하게 되므로 범위 내에서 트랜잭션 본질을 유지하기 쉬워진다.
미확인 예외를 사용하라
- 확인된 예외는 OCP(Open Closed Principle) 를 위반하다.
- 메서드에서 확인 예외를 던지더라도 catch 블록이 여러 단계 위에 있다면 그 사이 메서드 모두가 예외를 정의해야 한다. (
throw Exception)- 즉, 하위 단계 메서드의 코드를 변경시 상위 단계 메서드 선언부를 전부 고쳐야 한다는 말이다.
- 딘계를 내려갈수록 호출하는 함수 수는 늘어난다. throws 경로에 위치하는 모든 함수가 예외를 알아야하므로 캡슐화가 깨진다.
- 확인된 예외도 유용하지만 일반적인 애플리케이션은 의존성이라는 비용이 이익보다 크다.
예외에 의미를 제공하라
- 예외를 던질 땐 전후 상황을 충분히 덧붙인다.
- 그러면 오류 발생 원인과 위치를 찾기 쉬워진다.
- 자바는 모든 예외에 호출 스택을 제공하지만 실패한 코드의 의도를 파악하려면 호출 스택만으론 부족하다.
- 오류 메시지에 정보를 담아 예외와 함께 던지는게 좋다.
- 실패한 연산 이름과 실패 유형도 언급한다.
- 애플리케이션이 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 충분한 정보를 넘겨준다.
호출자를 고려해 예외 클래스를 정의하라
- 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는
오류를 잡아내는 방법이 되어야 한다. - 외부 API를 사용할 때는 감싸기 기법을 사용하면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다.
- 또한 나중에 다른 라이브러리로 갈아타도 비용이 적다.
감싸기(Wrapper) 클래스에서 외부 API를 호출하는 대신 테스트 코드를 넣어주는 방법으로 프로그램을 테스트하기도 쉬워진다.- 마지막으로 특정 업체가 API 를 설계한 방식에 발목 잡히지 않는다. 프로그램이 사용하기 편리한 API를 정의하면 그만이기 때문이다.
- 한 예외는 잡아내고 다른 예외는 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용하도록 한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
//나쁜 예시 - 예외에 대응하는 방식이 예외 유형과 무관하게 거의 동일하다.
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 {
....
}
//개선 - 예외를 잡아 유형을 반환하는 감싸기(wrapper) 클래스로 의존성 최소화
LocalPort port = new LocalPort(12);
try {
port.open();
} catch (PortDeviceFailure e) {
reportPortError(e);
logger.log(e.getMessage(), e);
} finally {
....
}
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);
}
}
}
정상 흐름을 정의하라
- 예외는 논리를 따라가기 어렵게 만든다.
- 가장 좋은 것은 특수 상황을 처리할 필요가 없는 것이다.
- 특수 사례 패턴은 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식이다.
- 특수 사례 패턴은 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하므로 클라이언트 코드가 예외적인 상황을 처리할 필요가 없게 만든다.
- 아래 예시에선
PerDiemMealExpenses클래스에 해당한다.
- 아래 예시에선
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
//나쁜 예시
try {
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();
} catch (MealExpenseNotFound e) {
m_total += getMealPerdiem();
}
//개선 - 특수 사례 패턴으로 예외를 처리할 필요가 없게 만듦.
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
m_total += expenses.getTotal();
public class PerDiemMealExpenses implements MealExpenses {
public int getTotal() {
//기본값으로 일일 기본 식비는 반환하는 코드
}
}
null을 반환하지마라.
- null을 반환하는 코드는 일거리를 늘릴 뿐만 아니라 호출자에게 문제를 떠넘긴다.
- 누구 하나라도 null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.
- 메서드에서 null을 반환하고픈 유혹이 든다면 예외를 던지거나 특수 사례 객체를 반환한다.
- 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외를 던지거나 특수 사례 객체를 반환하는 방식을 고려한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
//나쁜 코드 - null을 반환하는 getEmployees메서드.
List<Employee> employees = getEmployees();
if(employees != null) {
for(Employee e : employees) {
totalPay += e.getPay();
}
}
//개선 - getEmployee 메서드가 null이 아닌 빈 List를 반환하도록 수정한다. 코드가 훨씬 깔끔해지고 NPE 가 발생할 가능성도 줄어든다!
List<Employee> employees = getEmployees();
for(Employee e : employees) {
totalPay += e.getPay();
}
public List<Employee> getEmployees() {
if(...) //직원이 없다는 것을 확인하는 조건문
return Collections.emptyList();
}
null을 전달하지 마라
- 메서드 인수로 null을 전달하는 방식은 더 나쁘다.
1
2
3
4
5
6
7
8
public class MetricsCalculator {
public double xProjection(Point p1, Point p2) {
return (p2.x - p1.x) * 1.5;
}
...
}
calculator.xProject(null, new Point(12, 13)); // NPE 발생!!!
- 위와 같은 NPE 를 방지하려면
새로운 예외 유형을 만들어 던지거나,assert 문을 사용하여 메서드 내부에서 방어를 할 수 있을 것이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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;
}
...
}
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이 넘어오면 코드에 문제가 있다는 말이다.
- 이런 정책을 따르면 그만큼 부주의한 실수를 저지를 확률도 작아진다.
결론
- 깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다.
- 이 둘은 상충하는 목표가 아니다.
- 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려하면 튼튼하고 깨끗한 코드를 작성할 수 있다.
- 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.
Reference
- 예제 코드 출처