핵심 정리
메서드나 생성자를 작성할 때면 그 매개변수들에 어떤 제약이 있을지 생각해야 한다. 그 제약들을 문서화하고 메서드 코드 시작 부분에서 명시적으로 검사해야 한다. 이런 습관을 반드시 기르도록 하자. 그 노력은 유효성 검사가 실제 오류를 처음 걸러낼 때 충분히 보상받을 것이다.
메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다. 예컨대 인덱스 값은 음수이면 안 되며, 객체 참조는 null이 아니어야 하는 식이다. 이런 제약은 반드시 문서화해야 하며 메서드 몸체가 시작되기 전에 검사해야 한다. 이는 "오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다."는 일반 원칙의 한 사례이기도 하다.
메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을 때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다.
매개변수 검사를 제대로 하지 못할 때 문제점
- 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다.
- 메서드가 잘 수행되지만 잘못된 결과를 반환할 때다.
- 메서드는 문제없이 수행됬지만, 어떤 객체를 이상한 상태로 만들어놓아서 미래의 알 수 없는 시점에 이 메서드와는 관련 없는 오류를 낼 때다.
다시 말해 매개변수 검사에 실패하면 실패 원자성(failure atomicity)을 어기는 결과를 낳을 수 있다.
public과 protected 메서드는 매개변수 값이 잘못됬을 때 던지는 예외를 문서화해야한다. (@throws 자바독 태그 사용, 보통 IllegalArgumentException, IndexOutOfBoundsException, NullPointerException 발생)
매개변수의 제약을 문서화한다면 그 제약을 어겼을 때 발생하는 예외도 함께 기술해야 한다.
/**
* (현재 값 mod m) 값을 반환한다. 이 메서드는
* 항상 음이 아닌 BigInterger를 반환한다는 점에서 remainder 메서드와 다르다.
*
* @param m 계수(양수여야 한다.)
* @return 현재 값 mod m
* @throws ArithmeticException m이 0보다 작거나 같으면 발생한다.
*/
public BigInteger mod(BigInteger m) {
if (m.signum() <= 0)
throw new ArithmeticException("계수(m)는 양수여야 합니다. " + m);
... // 계산 수행
}
이 메서드는 m이 null이면 m.signum() 호출 때 NullPointerException을 던진다. 그런데 "m이 null일 때 NullPointerException을 던진다"라는 말은 메서드 설명 어디에도 없다.
// BigInteger의 class Doc
All methods and constructors in this class throw NullPointerException when passed a null object reference for any input parameter.
그 이유는 이 설명을 (개별 메서드가 아닌) BigInteger 클래스 수준에서 기술했기 때문이다. 클래스 수준 주석은 그 클래스의 모든 public 메서드에 적용되므로 각 메서드에 일일이 기술하는 것보다 훨씬 깔끔한 방법이다.
매개변수 유효성 검사 방법
1. java.util.Objects.requireNonNull 메서드 사용해 null 검사 방법(자바 7)
//매개 값 (T obj)이 not null이면 obj 리턴
//null이면 모두 NullPointerException을 발생
public static <T> T requireNonNull(T obj) {
if (obj == null)
throw new NullPointerException();
return obj;
}
//null 발생 시 message 전달
public static <T> T requireNonNull(T obj, String message) {
if (obj == null)
throw new NullPointerException(message);
return obj;
}
//Supplier를 구현한 익명 함수의 반환값을 메세지로 갖는 NPE 예외를 던진다.
public static <T> T requireNonNull(T obj, Supplier<String> messageSupplier) {
if (obj == null)
throw new NullPointerException(messageSupplier == null ?
null : messageSupplier.get());
return obj;
}
2. checkFromIndexSize, checkFromToIndex, checkIndex 메서드 활용
List<String> str_list = List.of("apple", "banana", "coke");
// Exception in thread "main" java.lang.IndexOutOfBoundsException:
// Index 4 out of bounds for length 3
Objects.checkIndex(4, str_list.size());
null 검사 메서드만큼 유연하지 않다. 예외 메세지를 지정할 수 없고, 리스트와 배열 전용으로 설계됬다. 또한 닫힌 범위(closed range; 양 끝단 값을 포함하는)는 다루지 못한다. 그래도 이런 제약이 걸림돌이 되지 않는 상황에서는 아주 유용하고 편하다.
3. public이 아닌 메서드라면 assert 키워드를 사용
//Java에서는 JDK1.4부터 assert라는 예약어를 지원
private static void sort(long a[], int offset, int length) {
//참이면 pass, 거짓이면 AssertionError
assert a != null;
//런타임에 아무런 효과도, 아무런 성능 저하도 없다.
//(단, java를 실행할 때 명령줄에서 -ea 혹은 --enableassertions 플래그를 설정하면
//런타임에 영향을 준다.
assert offset >= 0 && offset <= a.length;
assert length >= 0 && length <= a.length - offset;
... // 계산 수행
}
매개변수 유효성 검사 필요 없는 경우
1. 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때
2. 계산 과정에서 암묵적으로 검사가 수행될 때
예) Collections.sort(List) - 만약 상호 비교될 수 없는 타입의 객체가 들어 있다면 그 객체와 비교할 때 ClassCastException을 던질 것이다. 따라서 비교하기 앞서 리스트 안의 모든 객체가 상호 비교될 수 있는지 검사해봐야 별다른 실익이 없다.
이번 아이템을 "매개변수에 제약을 두는 게 좋다"고 해석해서는 안 된다.
사실은 그 반대다.
메서드는 최대한 범용적으로 설계해야 한다.
'일상 > 레벨업 독서' 카테고리의 다른 글
[이펙티브 자바] Item 55 옵셔널 반환은 신중히 하라. (0) | 2022.05.03 |
---|---|
[이펙티브 자바] Item 54 null이 아닌, 빈 컬렉션이나 배열을 반환하라 (0) | 2022.05.03 |
[이펙티브 자바] Item 48 스트림 병렬화는 주의해서 적용하라 (0) | 2022.05.02 |
[이펙티브 자바] Item 37 ordinal 인덱싱 대신 EnumMap을 사용하라. (0) | 2022.04.12 |
[이펙티브 자바] Item 36 비트 필드 대신 EnumSet을 사용하라. (0) | 2022.04.11 |