오류 코드보다 예외를 사용하라
if 문 등을 활용한 오류 처리 코드보다는 try~catch와 같은 예외 처리 코드를 사용해야한다.
if문은 중첩될수록 프로그램 성능도 저하되고, 구조도 복잡해진다. try~catch를 사용해서 예외 처리로 오류 코드와 로직을 분리해야한다.
try ~ catch ~ finally 부터 작성하라
try블록에서 예외가 발생하든 아니든 catch블록은 프로그램의 상태를 일관성 있게 유지해야한다. 그렇기 때문에 예외가 발생할 여지가 있는 부분에서는 try~catch~finally 구문을 먼저 작성하는 것이 좋다. 이렇게 작성하면 try블록에서 어떤 일이 발생하던지 간에 호출자가 기대하는 상태를 정의하기가 쉬워진다.
테스트 케이스를 작성하는 경우에는 예외를 발생시키는 케이스를 먼저 작성하고 테스트를 통과하게 하는 것이 좋다. 이렇게하면 자연스럽게 try블록의 트랜잭션 범위부터 구현하게 되기때문에 범위 내에서 트랜잭션 본질을 유지하기가 쉬워진다.
미확인 예외를 사용하라
확인된 예외(Checked Exception)는
JAVA에서 예외의 일종인RuntimeException클래스가 존재하는데, 이 클래스를 상속하는 예외들을 확인된 예외라고 합니다.
초기 자바에서는 확인된 예외를 사용하는 것이 좋은 생각이었으나, 현재는 안정적인 소프트웨어 개발을 위해 확인된 예외를 반드시 사용할 이유가 없다.
확인된 예외는 OCP(Open Closed Principal)를 위반한다. 어느 메소드에서 확인된 예외를 던졌으나 예외 처리하는 catch 구문이 세 블록 위에 있다면 모든 메소드 선언부에 예외를 정의해주어야한다. 다시말해 하위 단계에서 변경이 발생하면 상위 단계를 전부 수정해야한다는 것이다.
Open Closed Principal
SOLID 원칙 중 하나로, 소프트웨어는 확장에 대해서 열려있어야 하지만 변경에 대해서는 닫혀있어야한다는 원칙.
추후에 기능이 추가/변경되면 원래 코드를 변경하지 않고 코드의 추가만을 하도록 설계해야한다.
예외에 의미를 제공하라
예외를 throw할 때는 전후 상황을 충분히 덧붙인다. 이러면 오류가 발생한 원인과 위치를 찾기 쉬워진다.
오류 메세지에 정볼르 담아서 예외와 함께 던진다. 애플리케이션에 logging 기능이 있으면 기록하기 쉽도록 catch 구문에 정보를 충분히 넘겨준다.
호출자를 고려해 예외 클래스를 정의하라
프로그래머가 오류를 정의할 때 가장 중요하게 관심을 가져야하는 것은 오류를 잡아내는 방법이다.
외부 API를 사용하는 경우에는 감싸기 기법이 가장 좋은 방법이다.
- 외부 라이브러리와 프로그램간 의존성이 줄어든다.
- 다른 라이브러리로 교체가 쉬워진다.
- 테스트가 쉬워진다.
- 외부 API의 설계 방식에 의존하지 않아도 된다.
정상 흐름을 정의하라
예외 처리 구문을 작성하다보면 중단을 하고, 처리를 한 후 다시 중단된 계산을 처리하는 경우가 생긴다. 좋은 처리 방식이지만 특정 상황에서는 이런 중단 처리가 좋지 못할수도 있다.
이때는 클래스나 객체를 만들어서 예외처리를 하게 만들면 좋다.
null을 반환하지 마라
null을 반환하는 코드는 작업량(코드 줄)을 늘리며 호출자에게 문제를 떠넘기게 된다. 만약 null 확인을 까먹어버리면 애플리케이션은 통제 불능 상태가 될 수도 있다.
null을 전달하지 마라
메소드에 null을 전달하는 방식은 반환보다 더욱 나쁘다.
대다수의 프로그래밍 언어는 전달된 null에 대해 적절히 처리할 수 있는 방안이 없다. 그렇지 때문에 애초에 null을 전달하지 않도록 만드는 것이 좋다.
