DAY 13

🔖 오늘 읽은 범위 : 7장, 오류 처리 ~

<aside> 😃 책에서 기억하고 싶은 내용을 써보세요.

</aside>

• 오류 코드보다 예외를 사용하라.
• 호출 시점에 예외 핸들링이 효율적으로 가능하거나 예외를 강제하는 경우를 제외하고는 비확인 예외 사용(Java 만)
• 예외에 의미 제공하라(연산 이름+실패 유형+스택)
• “발생한 오류를 어떻게 잡아낼지”를 관점으로, 호출자를 고려한 예외 클래스를 정의하라 → wrapping 을 통한 공통 예외 유형을 반환하여 반복 작업을 없애고 단순화 하라. → 단순히 케이스별 반복적인 로깅이 아니라, 효율적으로 의존성을 줄이는 방법을 고안하라.

<aside> 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

</aside>

1. 근래에 Exception Handling을 IDE 가이드 대로 대충 처리해온 것 같아 반성하게 되었다. 앞으로 보다 명확하게 예외 플랜을 세워 핸들링을 해야겠다.

<aside> 🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.(또는 스스로의 과제)

</aside>

• 확인 예외 vs 비확인 예외 *결론: 호출 시점에 예외 핸들링이 효율적으로 가능하거나 예외를 강제하는 경우를 제외하고는 비확인 예외 사용(물론 Java만 해당) → 본문에서는 확인 예외가 호출된 상위 매서드마다 예외 처리를 야기(OCP 위반)시킬 수 있으므로, 확인 예외를 피하고 비확인 예외를 사용하라고 언급 → 책에 나온 C#, C++ 뿐만 아니라, Java 기반으로 만들어진 Kotlin에서도 확인 예외를 없앰 (다수가 확인 예외는 잘못된 사용으로 불필요한 자원 낭비를 야기시킬 수 있다고 판단하는 듯) → 하지만 API , 라이브러리 등 예외 핸들링을 강제해야 하는 경우에는 확인 예외가 유용 → Effective Java(Joshua Bloch) 에서는 호출자가 합리적으로 예외 처리가 가능한 경우 확인 예외를 사용하라고 함 (Use checked exceptions for conditions from which the caller can reasonably be expected to recover) → 확인 예외(Checked Exception)의 단점과 Unchecked Exception으로의 핸들링 방법(wrapping)에 대한 정리 블로그: https://phauer.com/2015/checked-exceptions-are-evil/

소감 3줄 요약

• 의미있는 예외를 구성하여 사용하라.
• (Java에서) 가급적 비확인 예외를 사용(Wrapping)하라. (Java만 외톨이…)
• 예외는 단순 기록이 아니라, 의존성을 줄이면서 “발생한 오류를 어떻게 잡아낼지”에 대한 정보를 제공해야 한다.