Effective Java - 메서드(method)
#38 매개 변수가 유효한지 검사하자
Effective Java - 메서드(method)
#38 매개 변수가 유효한지 검사하자
보통 메서드(method)나 생성자(constructor)는 매개 변수 값에 제한을 둡니다.
ex) int index는 0이거나 양수 여야 한다.
#01 getValue method이러한 제한들은 명확하게 문서화하고, 메서드 최상단에서 미리 검사해야 합니다.
당연한 얘기지만 에러를 미리 발견하거나, 유효하지 않은 매개 변수 값에 의한 여러 이슈들을 해결할 수 있기 때문입니다.
#01 문서화
public 메서드는 Javadoc의 @throws 태그를 이용해서 매개 변수 값이 제약을 위반했을 때 발생되는 예외를 문서화합니다.
#02 @throws 태그#02 Assertion
public이 아닌 메서드는 assertion을 이용해서 매개 변수를 검사합니다.
#03 assertassert는 지정한 조건이 true인지를 검사합니다.
만약 false이면 AssertionError가 발생합니다.
#04 AssertionError단, JVM을 실행할 때, -ea(또는 -enableas-sertions) 플래그를 지정하여 활성화시켜야지만 assert가 동작합니다.
#05 VM options안드로이드에서는 테스트 코드에서 많이 볼 수 있습니다.
#06 Android Unit test이와는 반대로 매개 변수의 제약을 미리 검사하지 않아야 하는 경우도 있습니다.
제약 검사(유효성 검사) 비용이 많이 듬.
제약 검사가 실용이 없음.
제약 검사가 메서드 내부 실행 중에 묵시적으로 수행되는 경우.
예를 들면 Collection.sort(List) 메서드들입니다.
이 메서드의 매개 변수인 List 값의 유효성을 미리 검사할 수 도 있지만, sort 메서드 내부에서 묵시적으로 검사를 하고 ClassCastException 예외를 발생시키고 있습니다.
따라서 사전에 제약 검사를 하는 건 의미가 없게 됩니다.
위 내용들처럼 매개 변수에 제약이 있다면 문서화나 assertion을 이용해야 하지만, 이를 지향해서는 안됩니다.
이용하기 좋게 제약이 적고 보편적인 메서드를 설계해야 합니다.
