책/이펙티브 자바
item 49 매개변수가 유효한지 검사하라
함께자라기
2022. 4. 13. 14:42
ITEM 49 매개변수가 유효한지 검사하라
메서드와 생성자 대부분은 입력 매개변수의 값이 특정 조건을 만족하기를 바란다
- 한 예로 인덱스 값은 음수면 안되고 객체 참조는 null이 아닌것
- 이러한 제약조건은 반드시 문서화 시켜야되며 메서드 몸체가 시작되기 전에 검사해야 한다
- 이건 오류는 가능한 한 빨리 (발생한 곳에서) 잡아야 한다 는 일반 원칙의 한 사례이기도 하다
- 오류를 발생한 즉시 잡지 못하면 해당 요류를 감지하기 어려워지고 감지하더라도 오류의 발생 지점을 찾기 어려워진다
- 메서드 몸체가 실행되기 전에 매개변수를 확인한다면 잘못된 값이 넘어왔을때 즉각적이고 깔끔한 방식으로 예외를 던질 수 있다
매개변수 검사를 제대로 하지 못하면 몇 가지 문제가 생길 수 있다
- 메서드가 수행되는 중간에 모호한 예외를 던지며 실패할 수 있다
- 더 나쁜 상황은 메서드가 잘 수행되지만 잘못된 결과를 반환하는 경우다
- 한층 더 나쁜 상황은 메서드는 문제없이 수행 됐지만 어떤 객체를 이상한 상태로 만들어 놓아서 미래의 알수 없는 지점에 이 메서드와는 관련 없는 오류를 내는 경우다
- 즉 매개변수 검사에 실패하면 실패 원자성(failure atomicity)을 어기는 결과를 낳을 수 있다
public과 protected 메서드는 매개변수 값이 잘못됐을 때 던지는 예외를 문서화해야 한다
- @throws 자바독 태그를 사용
- 보통은 IllegalArgumentException IndexOutOfBoundsException, NullPointerException 중 하나가 된다
- 매개변수의 제약을 문서화 하면 그 제약을 어겼을때 발생하는 예외도 함께 기술해야 한다
- 위와 같이 간단한 방법을 사용해서 API 사용자가 제약을 지킬 가능성을 크게 높일 수 있다
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, --enableaasertions 플래그 설정을 하면 런타임에 영향 있음
- 자세한건 별도 듀토리얼 참조
생성자는 나중에 쓰려고 저장하는 매개변수의 유효성을 검사하라는 원칙의 특수한 사례다
- 생성자 매개변수의 유효성 검사는 클래스 불변식을 어기는 객체가 만들어지지 않게 하는데 꼭 필요하다
메서드 몸체 실행 전에 매개변수 유효성을 검사해야 한다는 규칙에도 예외는 있다
- 유효성 검사 비용이 지나치게 높거나 실용적이지 않을 때
- 계산 과정에서 암묵적으로 검사가 수행될 때
이번 아이템 주제가 매개변수에 제약을 두는게 좋다는 것은 아니다
- 오히려 그 반대로 메서드는 최대한 범용적으로 설계해야 한다
- 메서드가 건네 받은 값으로 무언가 제대로 된 일을 할 수 있다면 매개변수 제약은 적을수록 좋다
- 하지만 구현하려는 개념 자체가 특정한 제약을 내재한 경우도 드물지 않다