8장 메서드

이번 장에서는 메서드 설계시 주의할 점을 살펴볼 것이다. 더 구체적으로는 사용성, 견고성, 유연성을 달성하기 위해 매개변수와 반환값의 처리, 메서드 시그니처의 설계, 문서화 방법 등을 다룬다. 8장의 내용 중 상당 부분은 생성자에도 적용돤다.

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

이번 item에는 메서드 매개변수의 처리방법을 다룬다.

메서드는 최대한 범용적으로 설계해야 하지만, 구현하려는 개념 자체가 매개변수에 제약을 내재한 경우도 드물지 않다.

예를 들면, 인덱스 값은 음수이면 안되고, 객체 참조는 null이 아니어야 한다는 식이다. 이런 제약은 반드시 문서화해야 하며, 메서드 몸체가 시작되기 전에 검사해야 한다.

이는 오류는 가능한 빨리 잡아야 한다는 일반 원칙과도 맞닿아있는 내용으로, 오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.

매개변수 유효성 검사를 제대로 하지 못하면

실패 원자성(failure atomicity)을 어길 수 있다.

• 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
• (더 나쁜 상황) 메서드가 잘 수행되지만 잘못된 결과를 반환할 수 있다.
• (더욱 나쁜 상황) 메서드는 문제없이 수행됐지만 어떤 객체를 이상한 상태로 만들어서 미래 알 수 없는 시점에 이 메서드와 관련없는 오류를 낸다.

public, protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다. @throws 자바독 태그를 사용하고, 예외 종류는 보통 IllegalArgumentException, IndexOutOfException, NullPointerException 중 하나일 것이다.

예외를 문서화할 때 참고할 점

• 매개변수의 제약을 문서화했다면, 어겼을 때 발생하는 예외도 기술한다.
• 클래스 수준 주석. 모든 예외를 기술하지 않고 해당 클래스 수준에 맞는 예외를 설명한다.
  • ex) BigInteger의 mod메서드 매개변수가 null이면 NPE를 던지지만 이에 대한 문서화는 하지 않는다.

예)

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

매개변수 Null Check 방법

1. (java 7) java.util.Objects.requireNonNull 메서드. 원하는 예외 메세지 지정이 가능하고 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다.

void test(Map<String,Object> param) {
		// 오버로딩으로 3가지로 구현돼어 있다.
		Objects.requireNonNull(param);
		Objects.requireNonNull(param, "param은 널입니다");
		Objects.requireNonNull(param, ()->"param은 널입니다.");
}

1. (java 9) checkFromIndexSize, checkFromToIndex, checkIndex 메서드. 예외 메시지를 지정할 수 없고, 리스트와 배열 전용으로 설계됐다. 닫힌 범위는 다루지 못한다.

int index = 4;
int length = 6;
int size = 2;
int toIndex = 2;

Objects.checkIndex(index, length); // index를 체크
Objects.checkFromIndexSize(fromIndex,size,length); // fromIndex, fromIndex + size 를 체크
Objects.checkFromToIndex(fromIndex,toIndex,length); // fromIndex, toIndex 를 체크

1. public이 아닌 메서드라면 assert를 사용 가능.

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

assert가 일반적 유효성 검사와 다른 점

• 실패하면 AssertionError을 던진다.
• 실행시 특정 옵션(-ea)을 줘야만 수행되기 때문에 런타임(상용)에선 아무런 효과도, 성능 저하도 없다.

생성자

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

매개변수 유효성을 검사하지 않는 경우

• 유효성 검사비용이 지나치게 높은 경우
• 계산 과정에서 암묵적으로 검사가 수행될 경우

예를 들어 Collections.sort(List) 처럴 객체 리스트를 정렬하는 메서드의 경우, 리스트 안의 객체들이 비교될 수 있어야 한다. 그런데 리스트의 정렬 과정에서 비교가 이뤄지므로 객체들이 상호 비교 가능한지 검사하는 것에 별다른 실익이 없다. 그러나 암묵적 유효성검사에 너무 의존했다가 실패 원자성을 해칠 수 있으니 주의하자.

정리

메서드나 생성자를 작성할 때 매개변수에 어떤 제약이 있을지 생각하자. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. 오류는 가능한 빨리 발생한 곳에서 잡아야 한다.