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

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

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

@@ -0,0 +1,149 @@
+## Item 70 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라.
+  - 자바는 문제 상황을 알리는 타입으로 검사 예외, 런타임 예외, 에러 이렇게 세 가지를 제공한다.
+  - 언제 무엇을 사용해야 하는지 좋은 지침들이 있다.
+<br>
+
+### 오류(Error)
+  - 시스템에 비정상적인 상황이 생겼을 때 발생
+  - 시스템 레벨에서 발생하기 때문에 심각한 수준의 문제상황
+
+### 예외(Exception)
+  - 개발자가 구현한 로직에서 발생
+  - 예외는 발생할 상황을 미리 예측하여 처리할 수 있음
+  - 예외는 개발자가 처리를 할 수 있기 때문에 예외를 구분하고, 그에 따라 처리 방법을 명확히 알고 사용하는 것이 중요함
+
+### 검사 예외(Checked Exception)
+  - 컴파일 단계에서 명확하게 Exception 체크가 가능한 것
+  - 반드시 예외 처리를 해주어야 함
+  - 컴파일 단계에서 확인
+  - ex) ClassNotFoundException, IOException
+
+### 런타임 예외(Runtime Exception)
+  - 실행과정 중 발견됨 
+  - 명시적인 처리를 강제하지 않음
+  - ex) NullPointerException, IndexOutOfBoundException
+
+
+![image](https://user-images.githubusercontent.com/50076031/112141375-8eee0780-8c18-11eb-8c37-3f51af416616.png)
+
+https://www.nextree.co.kr/p3239/
+
+[`예외처리 - try~catch 문, throws문, 예외의 종류`](https://butter-shower.tistory.com/87)
+
+[`자바 Exception 개념 및 예외 처리란?`](https://limkydev.tistory.com/198)
+
+<br>
+
+<details>
+  <summary>Java 예외 리스트</summary>
+
+## java.io
+  - IOException
+  - CharConversionException
+  - EOFException
+  - FileNotFoundException
+  - InterruptedIOException
+  - ObjectStreamException
+  - InvalidClassException
+  - InvalidObjectException
+  - NotActiveException
+  - NotSerializableException
+  - OptionalDataException
+  - StreamCorruptedException
+  - WriteAbortedException
+  - SyncFailedException
+  - UnsupportedEncodingException
+  - UTFDataFormatException
+  - UncheckedIOException
+
+
+## java.lang
+  - ReflectiveOperationException
+  - ClassNotFoundException
+  - InstantiationException
+  - IllegalAccessException
+  - InvocationTargetException
+  - NoSuchFieldException
+  - NoSuchMethodException
+  - CloneNotSupportedException
+  - InterruptedException
+
+## 산술 예외
+  - IndexOutOfBoundsException
+  - ArrayIndexOutOfBoundsException
+  - StringIndexOutOfBoundsException
+  - ArrayStoreException
+  - ClassCastException
+  - EnumConstantNotPresentException
+  - IllegalArgumentException
+  - IllegalThreadStateException
+  - NumberFormatException
+  - IllegalMonitorStateException
+  - IllegalStateException
+  - NegativeArraySizeException
+  - NullPointerException
+  - SecurityException
+  - TypeNotPresentException
+  - UnsupportedOperationException
+
+## java.net
+  - HttpRetryException
+  - SocketTimeoutException
+  - MalformedURLException
+  - ProtocolException
+  - SocketException
+  - BindException
+  - ConnectException
+  - NoRouteToHostException
+  - PortUnreachableException
+  - UnknownHostException
+  - UnknownServiceException
+  - URISyntaxException
+
+## java.text
+  - ParseException
+
+## java.time
+  - DateTimeException
+
+</details>
+
+<br>
+
+### 검사 예외
+  - 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.
+  - 이것이 검사와 비검사 예외를 구분하는 기본 규칙이다.
+  - 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
+  - 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
+
+<br>
+
+### 비검사 - 런타임 예외, 에러
+  - 둘 다 동작 측면에서는 다르지 않다.
+  - 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.
+  - 이는 복구가 불가능하거나 더 실행해봐야 득보다 실이 많다는 뜻이기 때문이다.
+  - 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자.
+  - 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
+    - 예컨대 배열의 인덱스는 0 ~ '배열 크기 - 1' 사이어야 한다.
+  - 복구할 수 있는 상황인지, 프로그래밍 오류인지 항상 명확히 구분되지 않는다는게 문제이다.
+  - 예를 들어, 자원 고갈은 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수 있고,
+  - 진짜로 자원이 부족해서 발생한 문제일 수도 있다.
+  - 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용하자.
+  - 확신하기 어렵다면 비검사 예외를 선택하는 편이 나을 것이다(아이템 71)
+
+<br>
+
+### 에러
+  - 에러는 보통 JVM이 자원 부족, 불변식 깨짐 등의 상황일 때 사용한다.
+  - Error 클래스를 상속해 하위 클래스를 만드는 일은 자제하기 바란다.
+  - Error는 상속하지 말아야 할 뿐 아니라, throw 문으로 직접 던지는 일도 없어야 한다.
+
+<br>
+
+### 핵심 정리
+  - 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자.
+  - 확실하지 않다면 비검사 예외를 던지자.
+  - 검사 예외도 아니고, 런타임 예외도 아닌 throwable은 정의하지도 말자.
+  - 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자.
+
+[`9 Best Practices to Handle Exceptions in Java`](https://stackify.com/best-practices-exceptions-java)