1. 왜 메시지에 실패 관련 정보를 담는 걸까?

• 예외를 잡지 못해 프로그램이 실패하면 자바 시스템은 그 예외의 stack trace 정보를 자동으로 출력한다.
• 이 stack trace는 예외 객체의 toString() 메서드를 호출하여 얻는 문자열로, 보통은 예외의 클래스 이름 뒤에 상세 메시지가 붙는 형태다.
• 일반적으로 이 정보들이 실패 원인을 분석해야 하는 프로그래머 혹은 사이트 신뢰성 엔지니어가 얻을 수 있는 유일한 정보인 경우가 많다.
  • 더욱이 해당 실패를 재현하기가 어렵다면 더 자세한 정보를 얻기가 어렵거나 불가능하다.
• 이런 이유로 예외의 toString() 메서드에 실패 원인에 대한 정보를 가능한 한 많이 담아 반환하는 일이 아주 중요한 것이다.

2. 실패 정보 담기

• 실패 순간을 포착하려면 발생한 예외에 관여된 모든 매개변수와 필드 값을 실패 메시지에 담아야 한다.
• 예를 들어 IndexOutOfBoundsException의 상세 메시지는 범위의 최솟값과 최댓값, 그리고 그 범위를 벗어났다는 인덱스의 값을 담아야 한다.
• 이 정보들은 실패에 관한 많은 것들을 알려준다. 저 3개의 값 중 한 개나 두 개, 전체가 잘못되었을 수 있다.
  • 예를 들어 인덱스가 최솟값보다 1만큼 작거나 최댓값과 같을 수도 있다.
  • 혹은 범위를 아주 크게 벗어났을 수도 있다.
• 실패에는 여러 원인들이 있을 수 있으며 원인들에 따라 고쳐야 하는 방법도 다르다. 이러한 관점에서 저러한 정보를 가지고 있을 때 어떻게 고쳐야 하는지에 대한 대안을 쉽게 도출할 수 있다.

장황할 필요는 없다.

• 관련 데이터를 모두 넣는게 좋다고는 하지만 너무 장황하게 할 필요는 없다.
• 문제를 분석하는 사람은 stack trace 뿐만 아니라 소스 코드와 관련 문서를 함께 살펴보기 때문이다.
• stack trace에는 일반적으로 예외가 발생한 파일 이름과 줄 번호는 물론, 스택에서 호출한 다른 메서드의 파일 이름과 줄 번호까지 정확히 기록되어 있는 게 보통이다.
  • 따라서 이런 문서나 소스코드에서 얻을 수 있는 정보들은 길게 늘어나봐도 군더더기가 될 뿐이다.

상세 메시지와 오류 메시지를 혼동해서는 안 된다.

• 예외에서 문제의 원인을 담아 보내는 상세 메시지와 최종 사용자에게 보여줄 오류 메시지를 혼동해서는 안된다.
• 최종 사용자에게는 친절한 안내 메시지를 보여줘야 하지만 예외 메시지는 가독성보다 담긴 내용이 더 중요하기 때문이다.
  • 무엇보다 최종 사용자는 자신이 사용하는 서비스에 대한 오류에 대해 어떻게 대처해야 할지를 메시지로 받길 원하지 내부 데이터가 어떻게 되어 있는지 알고 싶지는 않을 것이다.
  • 또한 예외 메시지의 주 소비층은 문제를 분석해야 할 개발자이다. 이러한 이유로 오류 메시지의 경우 현지화를 하기도 하나, 예외 메시지는 그런 일이 거의 없다.