75_예외의_상세메시지에_실패_관련_정보를_담으라_최락준.md

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

checked vs unchecked

checked Exception

컴파일러가 에러 가능성을 발견(checked) 했지만 이를 처리할 수 없는 경우를 뜻함.

• 컴파일러가 처리하지 못하므로 클라이언트가 반드시 처리해야 함.
• 클라이언트가 처리할 수 있다면 checked Exception을 사용한다.

uncheck Exception

컴파일러가 에러 가능성을 발견하지 못함(unchecked)

• 컴파일러가 발견하지 못했다는 것은 코드의 문제가 아닌 로직의 문제라는 뜻이다.
• 따라서 클라이언트가 이를 처리할 수 없다.

예외의 상세 메시지의 중요성

• 예외 정보가 프로그램 실패에 대해 얻을 수 있는 유일한 정보인 경우가 많다.
• 프로그램이 실패한 경우를 재현하기 힘들 때 더 자세한 정보를 얻는 것이 어렵다.

실패 메시지

• 예외에 관여된 모든 매개변수와 필드의 값을 담아야 한다.
• 예외 메시지는 장황해서는 안되지만, 가독성보다는 담긴 내용이 훨씬 중요하다.
• 예외 메시지를 읽는 사람이 사용자가 아닌 프로그램을 분석할 프로그래머이기 때문이다.
• 예외 생성자를 통해 예외와 관련된 정보를 받아 상세 메시지를 미리 생성하는 방법도 괜찮다.

public IndexOutOfBoundsException(int lowerBound, int upperBound,
                                     int index) {
        super(String.format(
                "최솟값: %d, 최댓값: %d, 인덱스: %d",
                lowerBound, upperBound, index));

	//프로그램에서 사용할 수 있도록 실패 정보를 저장
        this.lowerBound = lowerBound;
        this.upperBound = upperBound;
        this.index = index;
    }

접근자 메서드

• 실패와 관련된 정보를 제공하는 메서드
• 접근자 메서드는 비검사 예외보다 검사 예외에서 더 빛을 발하지만 비검사 예외에도 접근자 메서드를 제공하는 것이 좋다.

비검사 예외보다 검사 예외에서 더 유용한 이유?

비검사 예외는 대부분 로직의 오류로 인한 예외이다. 따라서 예외 발생시의 관련 정보를 프로그램적으로 접근하는 것은 큰 도움이 되지 않는다. 하지만 이러한 정보도 결국 로직 상의 문제를 발견하는데 도움이 될 수도 있다.