Item76. 가능한 한 실패 원자적으로 만들라! Intro 작업 도중 예외가 발생해도 그 객체는 여전히 정상적으로 사용할 수 있는 상태라면 좋을 것이다. 그러려면, 호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 한다. 실패 원자적인 메서드를 만드는 방법 불변 객체로 설계 ...

Item75. 예외의 상세 메시지에 실패 관련 정보를 담으라! Intro 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택 추적 정보를 자동으로 출력한다. System.out.println(e.printStackTrace()); 스택 추적은 예외 객체의 toString 메서드를 호...

Item74. 메서드가 던지는 모든 예외를 문서화하라! Intro 메서드가 던지는 예외는 올바른 메서드 사용에 아주 중요한 정보다. 따라서 각 메서드가 던지는 예외 하나하나를 문서화하는 데 충분한 시간을 쏟아야 한다. 조언 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정...

Item73. 추상화 수준에 맞는 예외를 던지라! Intro 메서드가 저수준 예외를 처리하지 않고 바깥으로 전파해버릴 때 종종 수행하려는 일과 관련 없어 보이는 예외가 툭 튀어나올 수 있다. 이러면 당황할 것이다. 물론 당황에만 그치지 않고, 내부 구현방식을 드러내어 윗 레벨의 API를 오염시킨다. 다음 릴리즈에...

Item72. 표준 예외를 사용하라! Intro 숙련된 프로그래머는 그렇지 못한 프로그래머보다 더 많은 코드를 재사용한다. 예외도 마찬가지다. 재사용하는 것이 좋으며, 자바 라이브러리는 대부분 API에서 쓰기에 충분한 수의 예외를 제공한다. 표준 예외 사용의 장점 작성한 API가 다른 사람이 익히고 사용하기 쉬워진다는 점이다. ...

Item71. 필요 없는 검사 예외 사용은 피하라! 검사 예외 결과를 코드로 반환하거나 비검사 예외를 던지는 것과 달리, 검사 예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해준다. 물론, 검사 예외를 과하게 사용하면 오히려 쓰기 불편한 API가 된다. 검사 예외를 던질 수 있다고 선언됐으면, 호출 시 c...

Item70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라! Intro 자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러, 이렇게 세 가지를 제공한다. 언제 무엇을 사용해야 하는지 헷갈리지 않도록 참고할만한 좋은 지침들을 소개하는 아이템이다. 지침 1. 호출하...