[#70][A팀] 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

[#70][A팀] 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

10장/70_복구할_수_있는_상황에는_검사예외를_프로그래밍_오류에는_런타임예외를_사용하라_신선영.md

@@ -0,0 +1,42 @@
+# item 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
+
+# 🐹 검사 예외**(Checked Exception)**
+
+- 반드시 예외처리를 해야한다.
+    - `throw`, `try-catch`를 이용하여 예외처리를 강제화한다.
+    - 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용해야한다.
+- 복구에 필요한 정보를 알려주는 메소드를 정의하는게 좋다.
+    - 예를 들어 물건을 구입하는데 잔고가 부족하다면, 잔고가 얼마나 부족한지 알려줘야한다. (아이템 75)
+
+# 🐭 비검사 예외 (Unchecked Exception)
+
+- 종류
+    - 런타임 예외
+    - 에러
+- 프로그램에서 잡을 필요가 없다.
+    - 복구가 불가능하거나 더 실행해봤자 의미가 없기 때문 → 예외처리를 강제화하지 않는다.
+    - 프로그래밍 오류를 나타낼 때에는 비검사 예외를 사용해야한다.
+- 우리가 구현하는 비검사 예외는 모두 `RuntimeException`을 상속 받아야한다.
+    - `Error`는 상속 받지 말아야할 뿐만아니라, 직접 `throw` 하는 일도 없어야한다. (`AssertionError` 제외)
+    - `Exception`, `RuntimeException`, `Error`를 상속하지 않은 `throwble`은 만들지 말자
+        - 이로운 것이 없다.
+        - API 사용자에게 혼동을 줄 수도 있다.
+
+뭘 사용할지 모르겠다면 아마 비검사 예외를 사용하는 것이 더 나을 것이다 (아이템 71 참고)
+
+# ❤ 결론
+
+- 복구해야하는 상황이면 → **검사 예외**
+- 프로그래밍 시 나타나는 오류라면 → **런타임 예외**
+- 확실하지 않은 예외라면 → **비검사 예외**
+- `Error` 클래스를 상속해 하위 클래스를 만드는 일 → **하지말자**
+- `Exception`, `RuntimeException`, `Error`를 상속하지 않은 `throwble` → **만들지 말자**
+
+# 💌 더 읽어볼 거리
+
+- [클린 코드 7장 - 오류 처리](http://amazingguni.github.io/blog/2016/05/Clean-Code-7-%EC%98%A4%EB%A5%98-%EC%B2%98%EB%A6%AC)
+- [Checked Exception을 대하는 자세](https://cheese10yun.github.io/checked-exception/)
+
+예외 복구 전략이 명확하고 그것이 가능하다면 Checked Exceptio을 try catch로 잡고 해당 복구를 하는 것이 좋습니다.
+
+**하지만 그러한 경우는 흔하지 않으며 Checked Exception이 발생하면 더 구체적인 Unchecked Exception을 발생시키고 예외에 대한 메시지를 명확하게 전달하는 것이 효과적입니다.**