From 903a59df45761907a57e8cdfff72d9ca90c527d7 Mon Sep 17 00:00:00 2001
From: Shinminjin <tlsalswls123@gmail.com>
Date: Sun, 19 May 2024 01:04:44 +0900
Subject: [PATCH] =?UTF-8?q?add:=20=F0=9F=93=B0=20[Item=2071]=20=ED=95=84?=
 =?UTF-8?q?=EC=9A=94=20=EC=97=86=EB=8A=94=20=EA=B2=80=EC=82=AC=20=EC=98=88?=
 =?UTF-8?q?=EC=99=B8=20=EC=82=AC=EC=9A=A9=EC=9D=80=20=ED=94=BC=ED=95=98?=
 =?UTF-8?q?=EB=9D=BC?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../chapter10/2024-05-19-item71.md            | 59 +++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 _posts/effective-java/chapter10/2024-05-19-item71.md

diff --git a/_posts/effective-java/chapter10/2024-05-19-item71.md b/_posts/effective-java/chapter10/2024-05-19-item71.md
new file mode 100644
index 0000000..6c9b1c7
--- /dev/null
+++ b/_posts/effective-java/chapter10/2024-05-19-item71.md
@@ -0,0 +1,59 @@
+---
+title: Item 71 - 필요 없는 검사 예외 사용은 피하라
+date: 2024-05-19 00:50:00 +0900
+categories: [이펙티브 자바, chapter10]
+tags: [이펙티브 자바]
+---
+
+검사 예외를 제대로 활용하면 프로그램의 안정성과 질을 높일 수 있다.
+
+## **검사 예외를 과하게 사용하면 🤔**
+
+- 검사 예외는 호출자가 처리해야 하는 강제성을 지니기 때문에 부담을 준다.
+    - `try-catch`로 처리하거나 `throws`를 던져 문제를 전파해야 한다.
+- 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용할 수 없어서 [*item 45~48*] 부담을 준다.
+- 특히, 메서드가 단 하나의 검사 예외만 던질 때 부담이 크다.
+    - 그 예외 하나 때문에 API 사용자는 try 블록을 추가해야 하고, 스트림에서는 사용 못하게 된다.
+    - 이런 상황에선 검사 예외를 안 던질 방법이 없는지 고민해보자.
+
+## **검사 예외 회피 방법 😎**
+
+### **(1) 옵셔널**
+
+- 적절한 결과 타입을 담은 옵셔널을 반환하는 것이 검사 예외를 회피하는 가장 쉬운 방법이다.
+- 검사 예외를 던지는 대신 단순히 빈 옵셔널을 반환하면 된다.
+- 그러나 이 방식은 예외가 발생한 이유를 알려주는 부가정보를 담을 수 없다는 단점이 있다.
+    - 예외를 사용하면, 구체적인 예외 타입과 메서드를 활용해 부가정보를 담을 수 있다.
+
+### **(2) 메서드 쪼개기**
+
+검사 예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿀 수 있다.
+
+```java
+// 검사 예외를 던지는 메서드 - 리팩터링 전
+try {
+    obj.action(args);
+} catch (TheCheckedException e) {
+    ... // 예외 상황에 대처한다.
+}
+```
+
+```java
+// 상태 검사 메서드와 비검사 예외를 던지는 메서드 - 리팩터링 후
+if(obj.actionPermitted(args)) {
+    obj.action(args);
+} else {
+    ... // 예외상황에 대처한다.
+}
+```
+- 모든 상황에 적용할 수 있는 리팩터링은 아니다.
+- 또한, 상태 검사 메서드의 단점도 그대로 적용된다. - *item 69*
+    - 외부 동기화 없이 여러 스레드가 동시에 접근할 수 있거나 외부 요인에 의해 상태가 변할 수 있다면 이 리팩터링은 적절하지 않다.
+    - 상태 검사 메서드(`actionPermitted`)가 상태 의존적 메서드(`action`)의 작업 일부를 중복 수행한다면 성능에서 손해이므로, 이 리팩터링이 적절하지 않을 수 있다.
+
+## **💡 핵심 정리**
+
+- 꼭 필요한 곳에서만 검사 예외를 사용하자.
+- API 호출자가 예외 상황에서 복구할 방법이 없다면 비검사 예외를 던지자.
+- 복구가 가능하고 호출자가 그 처리를 해주길 바란다면 옵셔널 반환을 고민하자.
+- 옵셔널만으로 상황을 처리하기에 충분한 정보를 제공할 수 없을 때만 검사 예외를 던지자.