뭔가 잘못될 가능성은 늘 존재한다. 그 잘못의 책임은 늘 우리 프로그래머에게 있다. 깨끗한 코드와 오류 처리는 확실히 연관성이 있다.
오류 코드보다 예외를 사용하라
- 이전에는 언어에서 예외를 지원하는 것이 필수가 아니었다.
- 제한적인 방법 ) 오류 플래그 설정, 호출자에게 오류 코드 반환 → 코드의 복잡성↑ (호출 즉시 확인해야 함)
- 👉 예외를 던져라!
Try-Catch-Finally 문 부터 작성하라
- try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있다.
- try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 한다.
- 코드가 예외를 던지므로 테스트가 성공한다.
- 코드의 목적에 따라 catch 의 예외 유형을 조정하라!
미확인 예외를 사용하라
- 확인된 예외의 문제
- 메서드를 선언할 땐 메서드가 반환할 예외를 모두 열거해야 함
- 코드가 메서드를 사용하는 방식이 메서드 선언과 일치하지 않으면 컴파일 불가능
- OCP를 위반 (하위 단계에서 코드 변경 시 상위 단계의 메서드 선언부를 변경해야 함)
- 캡슐화 깨지며 대규모 시스템에 취약 (최하위 함수를 변경해 새로운 오류를 던질 때, 함수는 선언부에 throws 절을 추가해야 함)
- 확인된 예외가 필요한 경우
- 중요한 라이브러리를 작성할 때 (모든 예외를 잡아야 함)
🔎 OCP(Open Closed Principle) : 확장에 대해서는 개방, 변경에 대해서는 폐쇄되어야 한다. (이전에 나왔었던 개념)
예외에 의미를 제공하라
👉 예외를 던질 때 전후 상황을 충분히 덧붙이면 오류가 발생한 원인과 위치를 찾기 쉬워진다.
- 어떤 언어는 모든 예외에 호출 스택을 제공하지만, 그것만으로는 부족하다.
- 오류 메시지에 정보(+ 실패한 연산 이름과 실패 유형)를 담아 예외와 함께 던진다.
- 애플리케이션에서 로깅 기능을 사용한다면 catch 블록에서 오류를 기록하도록 정보 남기기!
호출자를 고려해 예외 클래스를 정의하라
👉 애플리케이션에서 오류를 정의할 때 프로그래머에게 가장 중요한 관심사는 오류를 잡아내는 방법이 되어야 한다.
- 오류를 분류하는 방법
- 오류가 발생한 컴포넌트로 분류 가능
- 유형으로 분류 가능 (디바이스 실패, 네트워크 실패, 프로그래밍 오류)
- 대다수 상황에서 우리가 오류를 처리하는 일정한 방식
- 오류 기록
- 프로그램을 계속 수행해도 좋은지 확인
- 외부 API를 사용할 때 사용하는 감싸기 기법의 장점
- 외부 라이브러리와 프로그램 사이에서의 의존성이 ↓
- 다른 라이브러리로 대체하기에도 수월
- 프로그램 테스트 수월 (외부 API 호출 대신 테스트 코드 작성)
- 특정 업체의 API 설계에 제약되지 않음
정상 흐름을 정의하라
👉 특수한 상황을 처리할 필요가 없다면 더 좋지 않을까? 그러면 코드가 훨씬 더 간결해진다.
- 특수 사례 패턴 (객체를 조작해 특수 사례를 조작하는 방식)
- 객체가 예외적인 상황을 캡슐화하여 처리
- 클라이언트 코드가 예외적인 상황을 처리할 필요가 없어짐
null을 반환하지 마라
👉 null 반환은 오류를 유발하는 행위이다.
- null 반환 코드는 호출자에게 문제를 떠넘기는 것
- 대신 예외를 던지거나 특수 사례 객체를 반환하는 것으로 해결하라!
null을 전달하지 마라
👉 메서드로 null을 전달하는 방식은 반환보다 더 나쁘다!!
- 정상적인 인수로 null을 기대하는 API가 아니라면 금지!
- 대다수의 프로그래밍 언어에는 null을 처리하는 방법이 없다.
- 처음부터 null을 넘기지 못하도록 금지하는 정책이 합리적이다.
결론
👉 오류 처리를 프로그램 논리와 분리하면 독립적인 추론이 가능해지며 코드 유지보수성도 크게 높아진다.
인상 깊었던...
뭔가 잘못될 가능성은 늘 존재한다.
오류 처리 코드로 인해 프로그램 논리를 이해하기 어려워진다면 깨끗한 코드라 부르기 어렵다.
깨끗한 코드는 읽기도 좋아야 하지만 안정성도 높아야 한다. 이 둘은 상충하는 목표가 아니다.
노력하는 초보 개발자