노션에서 정리한 내용을 벨로그로 옮겼기 때문에 노션으로 보면 조금 더 보기 더 편합니다🤗
이동하기 → junnkk's Notion
오류 코드보다 예외를 사용하라
-
예외 X
-
오류 플래그 설정 or 호출자에게 오류 코드를 반환
→ 단점: 함수 호출 즉시 오류를 확인해야 하므로 호출자 코드가 복잡해짐.
-
-
예외 O
- 논리가 오류 처리 코드와 뒤섞이지 않으므로 호출자 코드가 더 깔끔해짐.
Try-Catch-Finally 문부터 작성하라
-
try-catch-finally 문에서 try 블록에 들어가는 코드를 실행하면 어느 시점에서든 실행이 중단된 후 catch 블록으로 넘어갈 수 있음.
→ 예외에서 프로그램 안에 범위를 정의한다
-
try 블록은 트렌잭션과 유사 → try 블록에서 무슨 일이 생기든지 catch 블록은 프로그램 상태를 일관성 있게 유지해야 함.
∴ 예외 발생할 코드는 try-catch-finally로 작성. (try 블록에서 무슨 일이 생기든지 호출자가 기대하는 상태를 정의하기 쉬워짐.)
-
강제로 예외를 일으키는 테스트 케이스를 작성한 후 테스트를 통과하게 코드를 작성하는 방법 권장함.
→ 자연스럽게 try 블록의 트렌젝션 범위부터 구현하게 되므로 범위 내에서 트랜젝션 본질을 유지하기 쉬워짐.
미확인 예외를 사용하라
-
확인된 예외는 필수적이지 않다.
∵ OCP 를 위반하기 때문. → 하위 단계에서 코드 변경 시 상위 단계 메서드의 선언부를 전부 고쳐야 함.
⇒ 캡슐화 깨짐
예외에 의미를 제공하라
-
예외를 던질 때 전후 상황을 충분히 덧붙인다.
→ 오류 발생 원인, 위치 파악 용이
∴ 오류 메세지에 정보를 담아 예외와 함께 던진다. ( 실패 연산 이름, 실패 유형 언급)
호출자를 고려해 예외 클래스를 정의하라
-
오류 분류 방법 多 - 오류 발생 위치 or 오류 발생 컴포넌트 or 유형 등등
-
but 오류 잡아내는 방법 가장 중요
-
감싸기 기법
-
외부 API를 이용할 때 유용
→ 외부 라이브러리와 프로그램 사이의 의존성 ↓
⇒ 라이브러리 교체 시 비용 ↓
-
외부 API 호출 대신 테스트 코드 넣어주는 방법으로 프로그램 테스트 하기도 용이
-
특정 업체가 API를 설계한 방식에 영향 받지 않음.
-
정상 흐름을 정의하라
→ 앞의 지침 따를 시 비즈니스 논리와 오류 처리가 잘 분리된 코드 작성 가능
-
특수 사례 패턴
: 클래스를 만들거나 객체를 조작해 특수 사례를 처리하는 방식
→ 클래스나 객체가 예외적인 상황을 캡슐화해서 처리하므로 클라이언트 코드가 예외적 상황을 처리할 필요 X
null을 반환하지 마라
-
null 반환 코드 ⇒ 일거리 ↑, 호출자에게 문제 떠넘김, NullPointerException 발생 가능성 ↑
-
해결책
-
예외 던지기 - 사용하려는 외부 API가 null을 반환한다면 감싸기 메서드를 구현해 예외 던지기
-
특수 사례 객체를 반환
예제) getEmployees를 변경해 빈 리스트 반환
-
null을 전달하지 마라
- NullPointException, InvalidArgumentException 발생 가능
- 해결책
- 새로운 예외 유형을 만들어 던지기 → 인자로 null 전달 시 InvalidArgumentException 발생
- assert 문 사용 - 문서화가 잘 되어있는 코드는 읽기 편하지만 문제 해결 x(null 전달 시 여전히 실행 오류 발생)
⇒ 대다수 프로그램은 호출자가 실수로 넘기는 null을 처리하는 방법이 없으므로 애초에 null을 넘기지 못하도록 금지해야 함.
결론
깨끗한 코드는 읽기에도 좋지만 안정성 높아야 함.
∴ 오류 처리를 프로그램 논리와 분리해 독자적인 사안으로 고려해야 함
⇒ 독립적인 추론 가능, 코드 유지보수성 ↑
→ 8장 경계
