[Effective Java] item 49 : 매개변수가 유효한지 검사하라

매개변수의 유효성 검사

• 메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바람
• 제약사항은 반드시 문서화해야 함
• 메서드 몸체가 시작되기 전에 검사해야 함
• "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다"는 일반 원칙

📌 제약사항은 반드시 문서화해야 함

• 특히, public, protected 메서드는 매개변수 값이 잘못되었을 때 던지는 예외는 문서화해야 함
• @throws 자바독 태그 사용하여 정리
• 보통은 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 중 하나
• 매개변수의 제약을 문서화하면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 함

/**
* (현재 값 mod m) 값을 반환한다. 이 메서드는 항상 음이 아닌 Biginteger률 반환하다는 점에서 remainder 메서드와 다르다.
*
* @param m 계수(양수여야 한다.)
* @return 현재 값 mod m
* @throws ArithmeticException mo| 0보다 작거나 같으면 발생한다.
*/
public Biginteger mod(Biginteger m) {
if (m.signum() <= 0)
throw new ArithmeticException ("계수 (m)는 양수여야 합니다. " + m);
... // 계산 수행
}

• 이 메서드는 m이 null이면 m.signum() 호출 때 NullPointerException을 던진다. 그런데 “m이 null일 때 NullPointerException을 던진다”라는 말은 메서드 설명 어디에도 없다.
• 이 설명을 (개별 메서드가 아닌) Biginteger 클래스 수준에서 기술했기 때문

클래스 수준 주석이 필요한 이유

• 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔한 방법

📌 메서드 몸체가 시작되기 전에 검사해야 함

• 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있음

이게 안 될 경우

• 메서드 수행 중간에 모호한 예외를 던지며 실패할 수 있음.

• 더 최악은, 메서드는 문제 없이 수행되었지만 어떤 객체를 이상한 상태로 만들어두어서, 미래의 알 수 없는 시점에 관련 없는 오류를 발생시킬 수 있음.

• 즉, 매개변수 검사에 실패하면 failure atomicity(실패 원자성)을 어기는 결과를 낳을 수 있음!

• 예외는 있다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산과정에서 암묵적으로 검사가 수행될 때 등이 있음

  • ex) Collections.sort(List) - 리스트 안의 객체들은 모두 상호 비교할 수 있어야 하며, 정렬 과정에서 이 비교가 이루어짐
  • 만약 상호 비교될 수 없는 타입의 객체가 들어있다면, 그 객체와 비교할 때 ClassCastException을 던짐
    => 이럴 경우, 비교하기에 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해보는 것보다는 버리는 게 나음

    하지만, 암묵적 유효성 검사에 너무 의존했다가는 실패 원자성을 해칠 수 있으니 주의!

📌 오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다

• 오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워지기 때문

기본적인 유효성 검사들

Null 검사

• @Nullable이나 이와 비슷한 애너테이션을 사용해 특정 매개변수는 null이 될 수 있다고 알려줄 수도 있지만，표준적인 방법은 아니다. 그리고 같은 목적으로 사용할 수 있는 애너테이션도 여러 가지다

• 자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니，더 이상 null 검사를 수동으로 하지 않아도 된다. 원하는 예외 메시지도 지정할 수 있다. 또한 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다.

  this.strategy = Objects.requireNonNull(strategy, "전략");

  • 반환값은 그냥 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용
    해도 됨

범위 검사

Objects의 checkFromlndexSize, checkFromToIndex, checkindex라는 메서드들을 사용하면 됨 (null 검사 메서드만큼 유연하지는 않음)

한계들

• 예외 메시지를 지정할 수 없고，리스트와 배열 전용으로 설계됐다.
• 닫힌 범위 (closed range； 양 끝단 값을 포함하는)는 다루지 못한다.

그래도 이런 제약이 걸림돌이 되지 않는 상황에서는 아주 유용하고 편하다

assert을 사용한 유효성 검사

• public이 아닌 메서드라면 단언문(assert)을 사용해 매개변수 유효성을 검증할 수 있다.

private static void sort(long a[], int offset, int length) {
  assert a != null;
  assert offset >= 0 && offset <= a.length;
  assert length >= 0 && length <= a.length - offset;
... // 계산 수행
}

• 여기서의 핵심은 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다는 것
• 이 메서드가 포함된 패키지를 클라이언트가 어떤 식으로 지지고 볶든 상관없다.

유의사항
단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다.
1. 실패하면 AssertionError를 던진다.
2. 두 번째, 런타임에 아무런 효과도, 아무런 성능 저하도 없다(단，java를 실행할 때 명령줄에서 -ea 혹은 --enableassertions 플래그 설정하면 런타임에 영향을 준다).💬

📌 “나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라”

• 이들은 특히 더 신경써서 검사해야 함
• 메서드가 유효하지 않은 값을 돌려주고, 나중에 그 인스턴스를 사용하려면 비로소 NullPointerException이 발생함
• 이 때가 되면 이 List를 어디서 가져왔는지 추적하기 어려워 디버깅이 상당히 괴로워질 수 있다.

생성자의 유효성 검사

생성자는 “나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라”는 원칙의 특수한 사례

• 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요함

📌 계산 중 잘못된 매개변수 값을 사용해 발생한 예외와 API 문서에서 던지기로 한 예외가 다를 수 있음

• 이럴 경우, 예외 번역(exception translate) 관용구를 사용하여 API 문서에 기재된 예외로 번역해줘야 함

📌 매개변수에 제약을 두는 게 좋다?

-> NO!

• 메서드는 최대한 범용적으로 설계해야 함

• 메서드가 건네받은 값으로 무언가 제대로 된 일을 할 수 있다면, 매개변수 제약은 적을수록 좋다.

• 단, 구현하려는 개념 자체가 특정한 제약을 내재한 경우도 드물지 않다!