kth496

이펙티브 자바 아이템 75 - 예외의 상세 메시지에 실패 관련 정보를 담으라

정리

• 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 스택트레이스를 자동으로 출력한다.
• 스택트레이스는 예외 객체의 toString() 메서드가 반환하는 문자열이다.
• 따라서 예외의 toString() 메서드에 실패 원인에 관한 정보를 가능한 한 많이 담아 반환하는 일이 중요하다.
• 실패 순간의 상황을 정확히 포착해 예외의 상세 메시지에 담아야 한다.
• 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다.(보안 관련 정보에 주의)
• 최종 사용자에게는 친절한 안내 메시지를 보여줘야 하지만, 예외 메시지는 가독성보다는 담긴 내용이 훨씬 중요하다.
• 아이템 70의 제안처럼, 예외는 실패와 관련한 정보를 얻을 수 있는 접근자 메서드를 적절히 제공하는 것이 좋다.

kth496

이펙티브 자바 아이템 74 - 메서드가 던지는 모든 예외를 문서화하라

• 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자.
• 공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가자.
• 비검사 예외도 정성껏 문서화해두면 좋다.
• 비검사 예외는 프로그래밍 오류를 뜻하므로, 무엇인지 알려주면 프로그래머는 해당 오류가 나지 않도록 코딩하게 된다.
• 잘 정비된 비검사 예외 문서는 그 메서드를 성공적으로 수행하기 위한 전제조건이 된다.
• 발생 가능한 비검사 예외를 문서로 남기는 일은 인터페이스 메서드에서 특히 중요하다.
• 메서드가 던질 수 있는 예외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자.
• 자바독 유틸리티는 throws와 @throws 태그로 동시에 명시된 예외와, @throws 태그로만 명시한 예외를 구분해준다.

kth496

이펙티브 자바 아이템 73 - 추상화 수준에 맞는 예외를 던지라

문제점

• 저수준 예외를 처리하지 않고 바깥으로 전파하면 안된다.
• 상황에 걸맞지 않은 예외로 인해 혼란을 불러온다.
• 내부 구현 방식을 드러내어, API를 오염시킨다.(구현 방식을 변경하면 다른 예외로 바뀔 가능성도 있다)

해결방법

• 상위 계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다.(예외 번역)

kth496

이펙티브 자바 아이템 72 - 표준 예외를 사용하라

표준 예외

• 표준 예외를 재사용하면 얻는 게 많다.
• 일단 우리가 만든 API가 다른 사람이 익히고 사용하기 쉬워진다. (익숙한 규약을 그대로 따르므로)
• 예외 클래스 수가 적을수록 메모리 사용량도 줄고, 클래스 적재 시간도 짧다

흔히 재사용되는 예외

1. IllegalArgumentException

• 호출자가 인수로 부적절한 값을 넘길 때 던지는 예외

kth496

이펙티브 자바 아이템 71 - 필요 없는 검사 예외 사용은 피하라

검사 예외의 문제

• 검사 예외는 제대로 활용하면 API와 프로그램의 질을 높일 수 있다.
• 하지만 남발하면 쓰기 불편한 API가 된다.
• 왜냐하면 호출 코드에서 catch 블록으로 예외를 붙잡거나, 혹은 더 바깥으로 전파해야 하기 때문
• 게다가 스트림에서 검사 예외 던지는 메서드가 사용불가하므로 부담이 된다.
• 더 나은 방식이 없다면 비검사 예외를 사용해야 한다.
• 메서드가 단 하나의 검사 예외만 던질 때가 특히 크다.
• 오직 하나의 예외 때문에 try-catch 블록을 추가해야 한다.

kth496

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

자바

• 자바에서 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 총 3가지를 제공한다.

언제 무엇을 써야할까?

1. 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.

• 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
• API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것이다.
• 그렇기 때문에 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공

kth496

이펙티브 자바 아이템 69 - 예외는 진짜 예외 상황에만 사용하라

사례

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

kth496

이펙티브 자바 아이템 68 - 일반적으로 통용되는 명명규칙을 따르라

철자 규칙

• 패키지, 클래스, 인터페이스, 메서드, 필드, 타입 변수의 이름을 다룬다.
• 특별한 이유가 없으면 반드시 따라야 한다.
• 패키지와 모듈 이름은 각 요소를 점으로 구분한다.
• 조직의 인터넷 도메인 이름을 역순으로 사용한다.(JLS, 6.1)
• 각 요소는 8자 이하의 짧은 단어로 한다.(utilities 보다는 util)
• 클래스와 인터페이스의 이름은 하나 이상의 단어로 이뤄지며 대문자로 시작한다.
• 통용되는 표현을 제외하고, 클래스명은 줄여쓰지 않는다.

kth496

이펙티브 자바 아이템 67 - 최적화는 신중히 하라

최적화에 대해

• 최적화는 좋은 결과보다는 해로운 결과로 이어지기 쉽다. 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어가 탄생하는 것이다.

• 성능 때문에 견고한 구조를 희생하지 말자.

• 빠른 프로그램보다는 좋은 프로그램을 작성하라.

kth496

이펙티브 자바 아이템 66 - 네이티브 메서드는 신중히 사용하라

자바 네이티브 메서드

• 자바 네이티브 인터페이스(JNI)는 자바 프로그램이 네이티브 메서드를 호출하는 기술
• 네이티브 메서드란 C, C++ 등의 네이티브로 작성된 메서드

왜 쓰나?

• 레지스트리 같은 플랫폼 특화 기능 사용