10장 예외 (week9)

[minSW]

10장 예외

Schedule : 21.07.07 (수) 9PM

목차

• 아이템 69. 예외는 진짜 예외 상황에만 사용하라
• 아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
• 아이템 71. 필요 없는 검사 예외 사용은 피하라
• 아이템 72. 표준 예외를 사용하라
• 아이템 73. 추상화 수준에 맞는 예외를 던지라
• 아이템 74. 메서드가 던지는 모든 예외를 문서화하라
• 아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라
• 아이템 76. 가능한 한 실패 원자적으로 만들라
• 아이템 77. 예외를 무시하지 말라

[KimYealynn]

아이템 69. 예외는 진짜 예외 상황에만 사용하라

• try-catch 블록에 넣으면 JVM이 적용할 수 있는 최적화가 제한된다.
• 특정 상태에서만 호출할 수 있는 '상태 의존적' 메서드를 제공하는 클래스는 '상태 검사' 메서드도 함께 제공해야 한다. ( iterator의 next hasNext )
  • 혹은 빈 옵셔널 / null같은 특정 값을 반환한다.
  • 세 옵션 선택 지침
  • 스레드가 동시 접근, 외부요인으로 상태가 변한다면 > 옵셔널, 특정 값
  • 성능이 요구 될 때 상태 검사/의존 메서드 간의 중복 작업이 있다면 > 옵셔널, 특정값
  • 다른 모든 경우 > 상태 검사 메서드 방식

아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

• 문제 상황을 알리는 3가지 타입 : 검사 예외 / 런타임 예외 / 에러
• 검사 예외 : 호출 하는 쪽에서 복구하리라 여겨지는 상황에서 사용
  • 호출자가 catch로 잡아 처리하거나 바깥으로 전파하도록 강제
  • 발생할 수 있는 상황임을 알리고 회복해내라고 요구하는 것
  • 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 제공
• 비검사 예외 (런테임 예외, 에러) : 잡을 필요가 없거나 잡지 말아야하는 예외
  • 런타임 예외 : 전제조건(API의 명세에 기록된 제약)을 지키지 못 했을 때
  • 에러 : JVM이 자원 부족, 불변식 깨짐 등 더이상 수행을 계속 할 수 없음을 나타냄
  • error를 직접 상속 X, 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
• 자원 고갈 상황에서 복구가 가능하다고 믿는다면 검사예외를, 그렇지 않다면 런타임 예외를, 확신하기 어렵다면 비검사 예외를

아이템 71. 필요 없는 검사 예외 사용은 피하라

• 검사 예외를 던지는 메서든는 스트림 안에서 사용 할 수 없다
• 검사 예외 비용 부담은 메서드가 단 하나의 검사 예외만 던질 때 가장 크다
• 옵셔널로 검사예외를 피할 수 있으나 발생 이유를 알려줄 수 없다.
• 검사 예외를 던지는 메서드를 2개로 쪼개서 비검사 예외로 던질 수 있다. try{ obj.action(args); } catch (TheCheckedException e) { } -> if (obj.actionPermitted(args) { obj.action(args); }

아이템 72. 표준 예외를 사용하라

• 예외 클래스 수가 적을수록 메모리 사용량도 줄고 클래스를 적재하는 시간도 적게 걸린다.
• IllegalArgumentException
• IllegalStateException (vs Argument.. 인수값이 무엇이든 실패했을 거라면 state)
• NullPointerException
• IndexOutOfBoundsException
• ConcurrentModificationException
• UnsupportedOperatinoException
• 예외는 직렬화할 수 있다 (12장)

아이템 73. 추상화 수준에 맞는 예외를 던지라

• 상위 계층에서는 저수준 예외룰 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다 (예외번역)
• 예외 번역시 저수준 예외가 도움이 된다면 예외 연쇄(exceptionChaning)을 사용

아이템 74. 메서드가 던지는 모든 예외를 문서화하라

아이템 75. 예외의 상세 메시지에 실패 관련 정보를 담으라

• 예외 메세지는 가독성보다는 담긴 내용이 중요하다. 주 소비자가 프로그래머, 엔지니어 이기 때문

아이템 76. 가능한 한 실패 원자적으로 만들라

• 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다.
• 실패 가능성이 있는 코드를 객체의 상태를 바꾸는 코드보다 앞에 배치한다.
• 작업 도중 발생하는 실패를 가로채는 복구 코드를 작성하여 작업 전 상태도 되돌린다.
• 항상 지켜질 순 없다. ex) 두 스레드가 동기화 없이 같은 객체를 동시에 수정하는 경우

아이템 77. 예외를 무시하지 말라

• 예외를 명시하는 까닥은 적절한 조취를 취해달라는 것
• 무시할 거면 catch 블록안에 그렇게 결정한 이유를 주석으로 남기고 예외 변수의 이름도 ignored로 바꾸자
• 무시하지 않고 바깥으로 전파되게만 해도 최소한의 디버깅 정보를 남긴 채 프로그램이 신속히 중단되게는 할 수 있다.

[minSW]

10장 예외

item 69

• 예외는 오직 예외 상황에서만 사용할 것
  • 일상적 제어 흐름용으로 사용 금지
  • 잘 설계된 API는 정상적 제어흐름에서 예외 사용할 일이 없음
• '상태 의존적' 메서드 제공 클래스는 '상태 검사' 메서드도 함께 제공
  • Iterator 의 next() (상태의존적), hasNext() (상태검사)
• 상태 검사 메서드 대신 빈 Optional / null / 특수 값 반환하는 방법
  • 외부 동기화 없이 여러 스레드가 동시 접근이 가능한 상황(non-thread safe)
  • 성능이 중요한 상황
  • 위 케이스 외에는 대부분 상태 검사가 나음

item 70

• 호출쪽에서 복구 할 수 있는 상황은 검사 예외
  • 복구에 필요한 정보를 알려주는 메서드도 제공할 것
• 프로그래밍 오류는 런타임 예외 (비검사 예외) 사용
• 커스텀 예외를 만들때 Error 는 상속하지 말 것
  • 우리가 구현하는 비검사 throwable은 모두 RuntimeException 하위일 것
• 검사 예외 vs 비검사 예외
  • Java의 예외처리는 모두 Throwable (Checked) 의 상속
  • 검사 (Checked) 예외 : Exception
  • 호출 시에 해당 예외에 대한 대비 필요
  • 비검사 (Unchecked) 예외 : Error, RuntimeException
  • 호출자에게 처리 의무 x (아무도 처리하지 않을시 JVM에서 처리됨)
  • 과도한 예외 검출은 시스템 성능 감소 야기
  • ref. https://madplay.github.io/post/java-checked-unchecked-exceptions

item 71

• 검사 예외는 API 사용자에게 부담
  • 검사 예외를 던지는 메서드는 stream 내에 직접 사용 불가?
• 비검사 vs 검사 예외
  • API를 제대로 사용해도 발생할 수 있는 예외 => 검사 예외
  • 프로그래머가 의미있는 조취를 취할 수 있는 경우 => 검사 예외
  • 이 외에는 => 비검사 예외
• p.393 하단 예제1 🤔
• 검사 예외 회피 방법 (주로 1개의 검사 예외)
  • 빈 옵셔널 반환 (단, 예외 발생 원인과 같은 부가 정보 x)
  • 검사 예외 메서드 => 상태 검사 메서드 + 비검사 예외 메서드
• 검사 예외는 꼭 필요한 경우에만
  • API호출자가 예외 상황에서 복구할 방법이 없다? => 비검사 예외
  • 복구할 수 있고 호출자가 처리해주길 바란다? => 옵셔널 반환
  • 옵셔널만으로는 복구를 위한 충분한 정보를 제공할 수 없다? => 검사 예외 사용 or 상태 검사 메서드 + 비검사 예외
  • 외부 요인에 의해 상태가 변할 수 있다면.. (상태검사 메서드 비적합) => 검사 예외 사용

item 72

• 재사용 & 표준라이브러리 사용의 장점 (item 59)
  • ex. IllegalArgumentException, ConcurrentModificationException, UnsupportedOperationException
  • IllegalStateException (인수 값이 무엇이든 어차피 실패했을 경우) vs IleegalArgumentException (인수 값에 관계가 있는 경우)
• "Exception, RuntimeException, Throwable, Error 는 직접 재사용 하지말자"
  • 여러 성격의 예외를 포괄하는 (추상)클래스 이므로 안정적 테스트 불가
• 예외의 이름과 던져지는 맥락이 부합할때 재사용
• "예외는 직렬화 할 수 있다"
  • 🤔 직렬화 부담. 나만의 예외를 새로 만들지 말아야할 근거?

item 73

• 예외 번역 (exception translation)
  • 상위 계층은 저수준 예외 잡아서 본인 추상화 수준 (상위) 예외로 바꿔 던짐
  • 즉, 저수준 예외를 본인 추상화 레벨로 '번역'
• 예외 연쇄 (exception chaining)
  • 문제의 근본 원인인 저수준 예외를 고수준 예외에 실어보내는 방식
  • Throwable.getCause() 로 꺼내기 가능
• 예외 번역이 그나마 낫지만, 가능한 저수준 메서드는 반드시 성공하는게 좋음
  • 예외를 피할 수 없다면 API호출자 까지는 전파하지 않도록..
  • 로깅 정도?

item 74

• 검사 예외는 항상 따로 선언, 각 예외 발생 상황을 @throws 로 정확히 문서화
  • Exception, Throwable 처럼 뭉뚱그린 선언은 지양
  • 예외 : main (JVM만 호출)
• 비검사 예외도 문서화해두면 좋다
  • 해당 메서드를 성공적으로 수행하기 위한 전제조건이 됨
  • 인터페이스 메서드에 특히 중요 (for 일관된 동작)
  • 단, @throws 에는 포함 X (검사 vs 비검사 예외 구분)
• 클래스 메서드들이 공통 이유로 같은 예외를 많이 던지면 클래스 설명에 추가하기도

item 75

• 실패 순간 포착 (stack trace, toString())
  • 발생한 예외에 관여된 모든 매개변수와 필드 값을 실패 메세지에 담을 것
• "예외는 실패와 관련된 정보를 얻을 수 있는 접근자 메서드를 적절히 제공하는게 좋다"
  • 검사 예외에서 빛을 발하지만 비검사 예외라도..

item 76

• 실패 원자적 (failure-atomic)
  • 호출 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지하는 특성
• 메서드를 '실패 원자적'으로 만드는 방법
  • 불변 객체로 설계
  • 작업 수행 전 매개변수 유효성 검사
  • 임시 복사본 객체에서 작업 수행 후 성공 시에 원래 객체와 교환
  • 작업 도중 발생 실패를 가로채는 복구 코드 작성
• 실패 원자성은 권장되지만 항상 달성할 수 있지도, 그래야하는 것도 아님
• 메서드 명세에 기술된 예외라면 실패시에 호출 전과 똑같이 유지되어야 한다는게 기본 규칙 (실패 원자성 보장)
  • 그럴 수 없다면 실패 시 객체 상태를 API 설명에 명시해야 함

item 77

• 예외를 무시하지 말자 (Do Nothing catch)
• 예외를 무시하기로했다면 catch 블록 내에 무시하는 이유를 주석으로 남길 것
  • 변수 이름도 ignored 를 사용할 것

[jin5335]

10장 예외

Item69 예외는 진짜 예외 상황에만 사용하라.

• 예외를 사용해서 프로그래밍 흐름을 제어하는 행동을 하지 마라.

  
  try {
  int i = 0;
  while(true)
      range[i++].climb();
  } catch (ArrayIndexOutOfBoundsException e) {
  }

for (Mountain m : range) m.climb();

  배열에 접근할 때 마다, 배열 경계인지 아닌지를 검사하는데 배열 경계 검사 중복을 피하기 위해 
try-catch를 사용했는데, 하지마라.
## Item70 복구할 수 있는 상황에는 검사예외를, 프로그래밍 오류에는 런타임 예외를 사용하라.
## Item71 필요없는 검사 예외 사용은 피하라.
* API를 제대로 사용해도 발생하는 예외 혹은 프로그래머가 예외를 **의미있게** 처리할 수 있으면 **검사 예외**를, 
아니라면 **비검사예외**를 사용해라.
## Item72 표준 예외를 사용하라.
* `IllegalArgumentException, IllegalStateException, IndexOutOfBoundsException` 등과 같이 표준 예외를 사용해라.
  - 내가 작성한 API를 다른 사람이 사용할때, 읽기 쉬워진다.
* `Exception, RuntionException, Throwable, Error`는 추상 클래스라고 생각하고 직접 재사용하지 말아라. 
## Item73 추상화 수준에 맞는 예외를 던지라.
* `예외 번역(exception translation)`: 상위 계층에서는 저수준 예외를 잡아, 자신의 추상화 수준에 맞는 예외로 바꿔 던저라.
  - 디버깅을 위해 저수준 예외가 필요하면, **예외 연쇄(exception chaining)`을 사용하는 것이 좋다. 
## Item74 메서드가 던지는 모든 예외를 문서화하라.
* **검사 예외**는 따로따로 선언하고, 자바독 `@throws` 태그를 사용하여 정확히 문서화화자. (뭉뚱그리기 ㄴㄴ)
* 검사예외는 메서드 선언의 throws 문에 일일이 선언하고, 비검사 예외는 메서드 선언에는 기입 ㄴㄴ (구분) 
## Item75 예외의 상세 메시지에 실패 관련 정보를 담으라.
* 발생한 예외에 관여된 **모든 매개변수와 필드의 값**을 실패 메세지에 담아라.
* 검사 예외라면, 복구를 위해 실패 메세지에 사용된 접근자 메서드를 구현해라.
(비검사 예외라면, 사용되는 경우는 거의 없으니 구현할 수 있으면 구현해라.)
## Item76 가능한 한 실패 원자적으로 만들라.
* `실패 원자적(failure-atomic)`: 호출된 메서드가 실패할 경우, 해당 객체는 메서드 호출 전 상태를 유지하는 특성
* 방법
  - 불변 객체로 설계
  - 작업 수행 전 매개변수의 유효성을 검사
    + 모든 실패할 가능성이 있는 코드를, 객체 상태를 변경하는 코드보다 앞에 배치
  -  임시 복사본에서 작업을 수행하고, 성공하면 객체 교환
  - 실패를 가로채는 복구 코드를 작성해서, 작업 전 상태로 되돌리기 (자주쓰이는 방법은 아님)
* 명세에 기록한 예외라면, **예외가 발생해도 객체의 상태는 메서드 호출 전과 똑같이 유지되는 것이 기본(failure-atomic)**이며,
  지키지 못한다면 **실패 시의 객체 상태를 명시**해라. 
## Item77 예외를 무시하지 말라.
* 빈 catch 블록으로 예외를 무시하지 마라.
* 예외를 무시해야하는 상황이라면, 예외 변수의 이름을 ignored로 사용하고 이유를 주석으로 남기자

try { } catch (TimeoutException ignored) { // 이유 기록 }

 ## Todo
- [ ] 에러와 예외 차이에 대해 조사해보기