Software Engineering Note

7장. 오류 처리 본문

스터디/Clean Code

7장. 오류 처리

devmoons 2014. 11. 25. 21:37

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



오류 코드를 확인하는 방법은 호출자 코드를 복잡하게 만든다. (if result == YES.. 따위) 


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


오류가 발생하면 예외를 던지는 편이 낫다. => 호출자 코드가 더 깔끔해진다. 논리가 오류 처리코드와 뒤섞이지 않는다.



미확인 예외를 사용하라 (RuntimeException 같은)



확인된 예외는 하위 단계에서 코드를 변경하면 상위 단계 메서드 선언부를 전부 고쳐야 한다.


최하위 함수를 변경해 새로운 오류를 던진다 -> 선언부에 throws 절 추가 -> 연쇄 수정 발생


결과적으로 최하위 함수에서 던지는 예외를 알아야 하므로 캡슐화가 깨진다!



예외에 의미를 제공하라



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


외부 API를 사용하는 경우 wrapper 클래스를 만들어 예외를 통일 시킬 수 있다.



null을 반환하지 마라


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


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


메서드에서 null을 반환하고픈 유혹이 든다면 예외를 던지거나 특수 사례 객체를 반환한다.


특수사례 객체 사용예


1. 사용전


List<Employee> employees = getEmployees();

if (employees != null) {

for(Employee e : employees) {

totalPay += e.getPay();

}

}


2. 사용 후


// 빈 리스트를 반환하도록 메소드를 수정한다.

public List<Employee> getEmployees() {

if (hasNoEmployee()) {

return Collections.emptyList();

}

}


List<Employee> employees = getEmployees();

for(Employee e : employees) {

totalPay += e.getPay();

}



null을 전달하지 마라


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


대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다.


그렇다면 애초에 null을 넘기지 못하도록 금지하는 정책이 합리적이다. 즉, 인수로 null이 넘어외면 코드에 문제가 있다는 말이다.

(assert 같은 구문을 이용해서 체크할 수 있다.)



'스터디 > Clean Code' 카테고리의 다른 글

9장. 단위 테스트  (0) 2015.08.08
8장. 경계  (0) 2014.11.25
6장 객체와 자료구조  (0) 2014.10.27
5장 형식 맞추기  (0) 2014.10.27
4장 주석  (0) 2014.10.27