매개변수가 유효한지 검사하라

메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다. 오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.

매개변수 검사를 하지 않았을 때의 문제

메서드가 수행되는 중간에 모호한 예외를 던지며 실패한다. 더 나쁜 상황은 메서드는 잘 수행되지만, 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 때다. 즉, 매개변수 검사에 실패하면 실패 원자성을 어기는 결과를 낳을 수 있다.

public과 protected 메서드의 예외

public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다(@throws 자바독 태그 사용). 매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다. 이런 간단한 방법으로 API 사용자가 제약을 지킬 가능성을 크게 높일 수 있다.

java.util.Objects.requireNonNull

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

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

반환값은 그냥 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용해도 된다. 이 외에도 자바 9에서는 Objects에 리스트와 배열 전용의 범위 검사 기능 메서드 checkFromIndexSize, checkFromToIndex, checkIndex가 추가 되었다.

private 메서드의 예외

공개되지 않은 메서드라면 패키지 제작자가 메서드가 호출되는 상황을 통제할 수 있다. 따라서 오직 유효한 값만이 메서드에 넘겨지리라는 것을 자신이 보증할 수 있고, 그렇게 해야 한다. 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;
	...
}

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

단언문과 일반적인 유효성검사의 차이

실패하면 AssertionError를 던진다.
런타임에 아무런 효과도, 아무런 성능 저하도 없다.(단, java를 실행할 때 -ea 혹은 –enableassertions 플래그를 설정하면 런타임에 영향을 준다.)

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

메서드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경 써서 검사해야 한다. 나중에 이 매개변수가 어디서 왔는지 추적하기 어려워 디버깅하기 어려워질 수 있다.

생성자는 “나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라”는 원칙의 특수한 사례다. 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요하다.

메서드 몸체 실행 전 매개변수 유효성 검사 규칙의 예외

유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때, 혹은 계산 과정에 암묵적으로 검사가 수행될 때다. 하지만 암묵적 유효성 검사에 너무 의존했다가는 실패 원장성을 해칠 수 있으니 주의해야 한다.

Collections.sort(List) 처럼 객체 리스트를 정렬하는 메서드의 경우, 리스트 안의 객체들은 모두 상호 비교될 수 있어야 하며, 정렬 과정에서 이 비교가 이뤄진다. 만약 상호 비교될 수 없는 타입의 객체가 들어 있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 비교하기 앞서 리스트 안의 객체를 검사해봐야 별다른 실익이 없다.

메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다.
이번 아이템을 “매개변수에 제약을 두는 게 좋다”고 해석하면 안된다. 사실은 그 반대로 메서드는 최대한 범용적으로 설계해야 한다. 메서드가 건네받은 값으로 무언가 제대로 된 일을 할 수 있다면 매개변수 제약은 적을수록 좋다.

Twitter Facebook LinkedIn