메소드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 예컨대 인덱스 값은 음수이면 안 되며, 객체 참조는 null이 아니어야 하는 식이다. 이런 제약은 반드시 문서화해야 하며 메소드 몸체가 시작되기 전에 검사해야 한다.
메소드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다. 매개변수 검사를 제대로 하지 못하면 메소드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다. 더 나쁜 상황은 메소드가 잘 수행되지만 잘못된 결과를 반환할 때이고, 한층 더 나쁜 상황은 메소드는 문제없이 수행됐지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메소드와는 관련 없는 오류를 낼 때다. 다시 말하면 매개변수 검사에 실패하면 실패 원자성(failure atomicity)을 어기는 결과를 낳을 수 있다.
public과 protected 메소드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다(@throws 자바독 태그를 사용하면 된다). 보통은 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 중 하나가 될 것이다. 이런 간단한 방법으로 API 사용자가 제약을 지킬 가능성을 크게 높일 수 있다.
자바 7에 추가된 java.util.Objects.requireNonNull 메소드는 유연하고 사용하기도 편하니, 더 이상 검사를 수동으로 하지 않아도 된다. 원하는 예외 메시지도 지정할 수 있으며, 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다. 반환값은 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용해도 된다.
1 2 | // 자바의 null 검사 기능 사용하기 this.strategy = Objects.requireNonNull(strategy, "전략"); | cs |
자바 9에서는 Objects에 범위 검사 기능도 더해졌다. checkFromIndexSize, checkFromToIndex, checkIndex라는 메소드들인데, null 검사 메소드만큼 유연하지는 않다. 예외 메시지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다. 또한 닫힌 범위(closed range, 양 끝단 값을 포함하는)는 다루지 못한다. 그래도 이런 제약이 걸림돌이 되지 않는 상황에서는 아주 유용하고 편하다.
패키지 제작자라면 공개되지 않은 메소드가 호출되는 상황을 통제할 수 있다. 따라서 오직 유효한 값만이 메소드에 넘겨지리라는 것을 보증할 수 있고, 그렇게 해야 한다. 다시 말해 public이 아닌 메소드라면 단언문(assert)을 사용해 매개변수 유효성을 검증할 수 있다.
1 2 3 4 5 6 7 | // 재귀 정렬용 private 도우미 함수 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; ... // 계산 수행 } | cs |
여기서의 핵심은 이 단언문들이 자신이 단언한 조건이 무조건 참이라고 선언한다는 것이며, 이 메소드가 포함된 패키지를 클라이언트가 어떤 식으로 지지고복든 상관없다. 단언문은 몇 가지 면에서 일반적인 유효성 검사와 다른데, 첫 번째, 실패하면 AssertionError를 던진다. 두 번째, 런타임에 아무런 효과도, 아무런 성능 저하도 없다.
메소드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다. 예를 들어 Objects.requireNonNull을 이용해 null 검사를 수행하면 클라이언트가 null일 때 NullPointerException을 던지는데, 이 검사를 생략했다면 해당 객체가 사용하려할 때 비로소 NullPointerException이 발생한다. 이때가 되면 문제가 되는 코드를 추적하기 어려워 디버깅이 상당히 괴로워질 수 있다.
생성자는 나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라는 원칙의 특수한 사례다. 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요하다.
메소드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외는 있다. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때다. 그렇다고 암묵적 유효성 검사에 너무 의존했다가는 실패 원자성을 해칠 수 있으니 주의하자.
때로는 계산 과정에서 필요한 유효성 검사가 이뤄지지만 실패했을 때 잘못된 예외를 던지기도 한다. 달리 말하면, 계산 중 잘못된 매개변수 값을 사용해 발생한 예외와 API 문서에서 던지기로 한 예외가 다를 수 있다. 이런 경우에는 예외 번역(exception translate) 관용구를 사용하여 API 문서에 기재된 예외로 번역해줘야 한다.
매개변수에 제약을 두는 게 좋다기 보단, 메소드는 최대한 범용적으로 설계해야 한다. 메소드가 건네받은 값으로 무언가 제대로 된 일을 할 수 있다면 매개변수 제약은 적을수록 좋다.
메소드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메소드 코드 시작 부분에서 명시적으로 검사해야 한다. 이런 습관을 반드시 기르도록 하자. 그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.