1. Error : 컴파일 시 문법적인 오류와 런타임 시 널포인트 참조와 같은 오류로 프로세스에 심각한 문제를 야기 시켜 프로세스를 종료 시킬 수 있습니다. Error는 시스템 레벨에서 발생하여, 개발자가 어떻게 조치할 수 없는 수준을 의미합니다

2. Checked Exception : 예외처리가 필수이며, 처리하지 않으면 컴파일되지 않습니다. JVM 외부와 통신(네트워크, 파일시스템 등)할 때 주로 쓰입니다.

   • RuntimeException 이외에 있는 모든 예외
   • IOException, SQLException 등

3. Unchecked Exception : 컴파일 때 체크되지 않고, Runtime에 발생하는 Exception을 말합니다.

   • RuntimeException 하위의 모든 예외
   • NullPointerException, IndexOutOfBoundException 등

1. 에러지침

검사예외(checked Exception)

1. 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.
   • 검사 예외를 던지면 호출자가 그 예외를 catch 로 잡거나 바깥으로 전파
   • 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
   • API 설계자는 사용자에게 검사 예외를 던져 그 상황에서 회복해내라고 요구하는 것이다.

예시) 쇼핑몰에서 물건을 구입하려는 데 카드 잔고가 부족하여 잔고가 얼마나 부족한지 알려주는 검사 예외

비검사예외(unchecked Exception)

• 런타임 예외와 에러가 포함된다.
• 프로그램에서 잡을 필요가 없거나 통상적으로 잡지 말아야 한다.
• 복구가 불가능하거나 더 실행해봐야 득보다 실이 많ㄴ다는 의미

1. 프로그래밍 오류 시 런타임 예외를 사용하라

   • 전제조건이 만족하지 못한경우(배열 크기 잘못설정 - ArrayIndexOutOfBoundsException)

2. 같은 상황이라도 복구가능이라면 검사 예외, 아니라면 런타임 예외를 사용하자(API 설계자의 판단에 달렸다.)

   • 예) 자원 고갈 시 잘못된 크기의 배열을 할당해 생긴 오류일 수 있고 진짜 자원이 일시적으로 부족해서 생긴 오류있수 있다

3. 에러는 더이상 수행을 계속할 수 없는 상황일때 쓰인다.

   • Error 클래스를 상속해 하위 클래스를 만들지 말자(업계 널리 퍼진 규약)
   • 모든 비검사 throwable 은 모두 RuntimeException 의 하위 클래스여야한다.

4. Exception, RuntimeException, Error 를 상속하지 않는 throwable 은 만들 수 있지만 절대 사용하지 말아라.

   • 정상적인 예외가 존재하는데 굳이 만들 이유가 있을까?
   • 오히려 API 사용자를 더 헷갈리게 만든다.

2. 비검사(unchecked Exception) 예외를 사용하라

Checked Exception vs Unchecked Exception

checked Exception

• try catch 의 경우 return -1 을 하면 해당 오류가 먼 곳에서 또다른 오류 야기 가능
  

• throws 로 에러를 상위 클래스로 전파시키면 시그니처 변경시 변경 요인이 많다 Open closed 원칙 위배.

• 해당 오류 해결은 클래스 내부에서 해결하는 것이 책임 관점에서 맞다고 본다.

unchecked exception

• 아예 실패해서 사용자에게 바로 알리는것이 더 적합하다. 빨리 실패하기

빨리 실패하기는 시스템은 문제가 일어났을 때 즉시 눈에 띄게 실패한다.

'즉시 눈에 띄게 실패'하게 하면 소프트웨어가 더 취약해질 것 같지만, 실제로는 더 견고해진다.

버그를 찾고 수정하기 더 쉬워지므로 프로덕션으로 가는 버그가 줄어든다.