메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족했을 때 제대로 동작해야 한다. 그리고 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다.
오류를 발생한 즉시 잡지 못하면 해당 오류를 감지하기 어려워지고, 감지하더라도 오류의 발생 지점을 찾기 어려워진다.
매개변수 검사를 제대로 못했을 경우 문제점
- 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
- 메서드는 잘 수행되었지만 잘못된 결과를 반환하는 경우도 있는데, 미래에 이 메서드와는 관련 없는 오류를 낼 위험이 있다.
- public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다(@throws 자바독 태그를 사용하면 된다).
- 매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다. 아래는 그 예시다.
public class Item49 {
/**
* (현재 값 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);
}
// 계산 수행
return null;
}
}- 이 메서드에서 m이 null이면 NullPointerException을 던진다는 말은 설명에 없다. 그 이유는 이 설명을 개별 메서드가 아닌 BigInteger 클래스 수준에서 기술했기 때문이다.
- 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔한 방법이다.
- 자바 7에 추가된 java.util.Objects.requireNonNull 메서드는 유연하고 사용하기도 편하니, 더 이상 null 검사를 수동으로 하지 않아도 된다.
원하는 예외 메시지도 지정할 수 있고, 입력을 그대로 반환하므로 값을 사용하는 동시에 null 검사를 수행할 수 있다. 아래는 Objects 클래스의 requireNonNull 메서드의 예시이다.
public class Item49 {
public static void main(String[] args) {
String nullTest = null;
Objects.requireNonNull(nullTest, "널이다.");
}결과
- 반환값은 무시하고 필요한 곳 어디서든 순수한 null 검사 목적으로 사용해도 된다.
- 자바 9에서는 Objects에 범위 검사 기능도 더해졌다.
- checkFromIndexSize, checkFromToIndex, checkIndex라는 메서드들이 있다.
단언문(assert)을 사용한 매개변수 유효성 검증
- 공개되지 않은 메서드라면 메서드가 호출되는 상황을 통제할 수 있다. 즉, public이 아닌 메서드라면 단언문(assert)을 사용해 매개변수 유효성을 검증할 수 있다.
ea 조건 추가
-
java default 실행에서는 assert가 모두 제외된다. 실행시 -ea 옵션을 줘야지만 작동하니 개발/테스트 일때는 설정해놓기
-
재귀 정렬용 private 도우미 함수
public class Item49 {
public static void main(String[] args) {
long a[] = new long[] {1,2,3};
sort(a, 0, 3);
}
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;
System.out.println("실행 완료");
}
}- 이 단언문들은 자신이 단언한 조건이 무조건 참이라고 선언한다. 참이 아닐경우 AssertionError가 발생한다.
- 단언문은 일반적인 유효성 검사와 다르다.
- 실패하면 AssertionError를 던진다.
- 런타임에 아무런 효과도, 아무런 성능 저하도 없다(단, java를 실행할 때 명령줄에서 -ea 혹은 --enableassertions 플래그 설정하면 런타임에 영향을 준다).
나중에 쓰기 위해 저장하는 매개변수의 유효성을 검사하라
[코드 20-1] 정적 팩터리 메서드
// 코드 20-1 골격 구현을 사용해 완성한 구체 클래스 (133쪽)
public class IntArrays {
static List<Integer> intArrayAsList(int[] a) {
Objects.requireNonNull(a);
// 다이아몬드 연산자를 이렇게 사용하는 건 자바 9부터 가능하다.
// 더 낮은 버전을 사용한다면 <Integer>로 수정하자.
return new AbstractList<>() {
@Override
public Integer get(int i) {
return a[i]; // 오토박싱(아이템 6)
}
@Override
public Integer set(int i, Integer val) {
int oldVal = a[i];
a[i] = val; // 오토언박싱
return oldVal; // 오토박싱
}
@Override
public int size() {
return a.length;
}
};
}
}- 메서드가 직접 사용하지는 않으나 나중에 쓰기 위해 저장하는 매개변수는 특히 더 신경써서 검사해야 한다. 한참 뒤에서야 문제가 발생할 수 있다.
- 생성자는 "나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라"는 원칙의 특수한 사례다.
- 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는 데 꼭 필요하다.
- "메서드 몸체 실행 전에 매개변수 유효성을 검사해야 한다"는 규칙에도 예외가 있다. 유효성 검사 비용이 지나치게 높거나 상용적이지 않을 때, 혹은 계산 과정에서 암묵적으로 검사가 수행될 때다.
- 다만, 암묵적 유효성 검사에 너무 의존하면 실패 원자성을 해칠 수 있으니 주의해야 한다.
핵심 정리
- 매개변수에 제약을 두는 게 좋다고 해석하면 안 된다. 메서드는 최대한 범용적으로 설계해야 한다.
- 메서드가 건네받은 값으로 제대로 동작할 수 있다면, 매개변수 제약은 적을수록 좋다.
- 메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 하며, 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다.
Enjoy to study