매개변수가 유효한지 검사하라
메서드와 생성자 대부분의 입력 매개변수의 값이 특정 조건을 만족하기를 바란다.
그렇기에 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다.
이는 "오류는 가능한 한 빨리 잡아야 한다"는 일반 원칙의 사례이기도 하다.
오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.
메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.
매개변수 검사를 제대로 하지 못하면 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
더 나쁜 상황은 메서드가 잘 수행되지만, 잘못된 결과를 반환할 때다.
한층 더 나쁜 상황은 메서 드는 문제 없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어 놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 때다.
다시 말해 매개변수 검사에 실패하면 원자성을 어기는 결과를 낳을 수 있다.
public과 protected 메서 드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다.
보통은 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 중 하나가 될 것이다.
매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다.
이때 @Nullable이나 이와 비슷한 애너테이션을 사용해 특정 매개변수는 null이 될 수 있다고 알려줄 수 있지만, 표준적인 방법은 아니다.
대신 자바 7에 추가된 java.util.Objects.requiredNonNull 메서드는 유연하고 사용하기 편하다.
또 자바 9에서는 Objects에서 범위 검사 기능도 더해졌다.
checkFromIndexSize, checkFromToIndex, checkIndex라는 메서드들인데, null 검사 메서도 만큼 유연하지는 않다.
예외 메시지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다.
또한 닫힌 범위는 다루지 못한다.
공개되지 않은 메서드라면 우리가 메서드 호출되는 상황을 통제할 수 있다.
따라서 오직 유용한 값만이 메서드에 넘겨지리라는 것을 우리가 보증할 수 있고, 그렇게 해야만 한다.
다시 말해 public이 아닌 메서드라면 단언문을 사용해 매개변수 유효성을 검증할 수 있다.
이때 핵심은 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언하는 것이다.
단언문은 몇 가지 면에서 일반적인 유효성 검사와 다르다.
첫 번째, 실패하면 AssertionError를 던진다.
두 번째, 런타임에 아무런 효과도, 아무런 성능 저하도 없다.
메서드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다.
생성자는 "나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라"는 원칙의 특수한 사례다.
생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요하다.
메서드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외는 있다.
유효성 감사 비용이 지나치게 많이 들거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때다.
이번 글을 "매개변수에 제약을 두는 게 좋다"고 해석해서는 안 된다.
그 반대다.
메서드는 최대한 범용적으로 설계해야 한다.
메서드가 건네받은 값은 무언가 제대로 된 일을 할 수 있다면 매개변수 제약은 적을수록 좋다.
하지만 구현하려는 개념 자체가 특정한 제약을 내재한 경우도 드물지 않다.
