[클린코드] 7. 오류 처리 - 요약 및 인사이트

인사이트 정리

 

어려워서 두 번정도 꼼꼼히 읽은 챕터이다. 

axios로 api를 호출할 때 api 하나당 try catch 하나로 일관되게 오류를 처리해왔는데  

지금의 방식이 책에서 말하는 감싸기 기법이나 특수 사례 객체를 사용하고 있는건지, 

더 나은 방법은 무엇인지 답을 내리기가 어려웠다. 오류처리를 프로그램 논리와 분리해야하는 것은 알겠는데..

객체지향 프로그래밍을 공부해야하는 것일까! 

 

요약

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

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

 

 

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

- 오류 플래그를 설정하거나 오류 코드를 반환하는 방법은 호출자 코드가 복잡해진다. 함수를 호출한 즉시 오류를 확인하는 단계를 잊어버리기 쉽다.

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

- 디바이스를 종료하는 알고리즘과 오류를 처리하는 알고리즘을 분리했기 때문이다. 

 

 

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

 

- 예외에서 프로그램 안에다 범위를 정의한다는 사실은 매우 흥미롭다. 

- try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다.

- try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야한다. 

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

 

 

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

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

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

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

- 아주 중요한 라이브러리를 작성한다면 모든 예외를 잡아야한다. 일반적인 어플리케이션은 의존성이라는 비용이 이익보다 크다. 

 

 

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

- 오류가 발생한 위치로 분류가 가능하다. 유형으로도 분류가 가능하다. 

- 대다수 상황에서 우리가 오류를 처리하는 방식은 비교적 일정하다. 1) 오류를 기록한다. 2) 프로그램을 계속 수행해도 좋은지 확인한다. 

- 호출하는 라이브러리 API를 감싸면서 예외 유형 하나를 반환하면 된다. ex) LocalPort 클래스는 ACMEPort클래스가 던지는 예외를 잡아 변환하는 감싸기 클래스일 뿐이다. 

- 실제로 외부 API를 사용할 때는 감싸기 기법이 최선이다. 외부 API를 감싸면 외부 라이브러리와 프로그램 사이에서 의존성이 크게 줄어든다. 

- 흔히 예외클래스가 하나만 있어도 충분한 코드가 많다. 한 예외를 잡아내고 다른 예외를 무시해도 괜찮은 경우라면 여러 예외 클래스를 사용한다. 

 

 

5. 정상 흐름을 정의하라 

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

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

 

 

6. null을 반환하지 마라 

- 첫째가 null을 반환하는 습관이다. null 확인을 빼먹는다면 애플리케이션이 통제 불능에 빠질지도 모른다.

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

 

 

7. null를 전달하지 마라 

- assert 문을 사용하는 방법도 있다. 문서화가 잘되어 코드 읽기는 편하지만 문제를 해결하지는 못한다.

- 대다수 프로그래밍 언어는 호출자가 실수로 넘기는 null을 적절히 처리하는 방법이 없다. 즉 인수로 null이 넘어오면 코드에 문제가 있다는 말이다. 

 

8. 결론

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

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