이미지가 깨져서 노션으로 보는 것을 추천드립니다.
위와 같은 리뷰 혹은 예외메시지를 적지 않아 날라오는 리뷰를 마추지거나 본 경험은 있을 것이다.
예외를 잡지 못 하고 프로그램이 실패하면 그 예외의 스택 추적(stack trace) 정보를 자동으로 출력한다.
스택 추적은 예외 객체의 toString 메서드를 호출해 얻는 문자열로 클래스 이름 뒤에 상세 메시지가 붙는 형태다.
이 정보는 프로그래머가 얻을 수 있는 유일한 정보인 경우가 많다. 실패를 재현하기 어렵다면 더 자세한 정보를 얻는 경우는 불가능에 가깝다. 예외의 toString 메서드에 실패 원인에 대한 정보를 가능한 많이 담아 반환하는 일은 중요하다.
위 스택 트레이스처럼 예외 메시지가 없다면 실패에 대한 원인을 분석하는 작업이 필요하다.
실패 순간을 포착하려면 발생한 예외에 관여한 모든 매개변수와 필드의 값을 실패 메시지에 담아야 한다.
최솟값, 최댓값, 인덱스를 모두 알려주는 경우
위 정보는 실패에 관한 많은 것을 알려준다.
하지만 모든 정보를 담는 건 안된다. 유저의 비밀번호나 보안과 관련된 정보는 담지 말자.
관련 데이터를 모두 담을 필요는 없다. 스택 트레이스에 파일과 라인은 기록되어 있기 때문에 장황하게 적는건 불필요한 작업이다. (어디서 부터 시작되서 어떻게 되고 이런 과정들은 적지 않아도 기록이 된다.)
예외의 상세 메시지와 최종 사용자에게 보여줄 오류 메시지를 혼동해서는 안 된다. 사용자에게는 친절한 안내 메지리를 보여줘야 하는 반면 예외 메시지는 가독성보다는 담긴 내용이 중요하다. 예외메시지의 주 소비층은 문제를 분석해야 할 프로그래머와 엔지니어기 때문이다.
실패를 적절히 포착하려면 상세메시지를 미리 생성하는 방법도 괜찮다.
적절하게 필드에 접근하는 메서드를 만들어 예외 상황을 복구하는 데 유용하게 사용할 수 있다. 비검사 예외보다는 검사 예외가 빛을 더 발한다. 75번 toString()이 반환한 값에 포함된 정보를 얻어올 수 있는 API를 제공하자는 원칙을 따르는 관점에서 비검사 예외라도 상세 정보를 알려주는 접근자 메서드를 제공하는 것을 권한다.
자바가 모두 의견을 수용해서 최댓값과 최솟값을 인자로 받는 생성자를 만들어 주진 않지만 조슈아 피셜 강력히 모든 예외 메세지를 전달하는 것을 권장한다.