[EffectiveJava] item27 - 비검사 경고를 제거하라
16 Apr 2023제네릭을 사용하기 시작하면 수많은 컴파일러 경고를 보게 될 수있다.
대부분의 비검사 경고는 쉽게 제거가 가능하다.
비검사경고 제거
아래와 같이 코드를 잘못 작성했을 때의 예시를 들어보자.
Set<Lark> exaltation = new HastSet();
자바 7 이후에는 다이아몬드 연산자(<>) 만으로 해결이 가능하기 때문에 대게 사용하지는 않지만 위와 같은 경우는 javac -Xlint:uncheck 옵션을 추가하면 경고가 사라진다.
그외에 제거하기 힘든 비검사 경고들도 있다. 하지만 할 수 있는 한 모든 비검사 경고를 제거하는 것이 좋다.
비검사경고를 제거한다면, 그 코드는 타입 안정성이 보장될 것이다. 즉, 런타임에 ClassCastException이 발생할 일이 없고, 우리들이 의도한 대로 잘 동작하리라 확신할 수 있을 것이다.
@SuppressWarnings
만약 경고를 제거할 수는 없지만 타입이 안전하다고 확신할 수 있다면 @SuppressWarnings(“unchecked”) 애너테이션을 달아 경고를 숨길 수있다. 단, 주의할 점이라면 타입 안전함을 검증하지 않은채 경고를 숨긴다면 스스로에게 잘못된 보안인식을 심어줄 수 있다. 해당 코드는 경고 없이 컴파일 되겠지만, 런타임에서 ClassCastException을 던질 수 있다.
@SuppressWarnings 애너테이션은 개별 지역변수 선언부터 클래스 전체 까지 어떤 선언에도 달 수 있다. 하지만 @SuppressWarnings 애너테이션은 항상 가능한 한 좁은 범위에 적용해야 한다. 자칫 심각한 경고를 놓칠 수 있으니 절대로 클래스 전체에 적용하면 안된다.
한 줄이 넘는 메서드나 생성자에 달린 @SuppressWarnings 애너테이션을 발견하면 지역변수 선언 쪽으로 옮기는 것이 좋다.
ArrayList에서 가져온 toArray메서드를 예로 들어보자. 해당 메소드에는 메소드 단위에 @SuppressWarnings 애너테이션이 붙어있다.
@SuppressWarnings("unchecked")
public <T> T[] toArray(T[] a) {
if (a.length < size)
// Make a new array of a's runtime type, but my contents:
return (T[]) Arrays.copyOf(elementData, size, a.getClass());
System.arraycopy(elementData, 0, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}
해당 메소드에서 @SuppressWarnings(“unchecked”)를 제거하고 ArrayList를 컴파일 하면 이메서드에서 다음 경고가 발생한다.
ArrayList.java:305: warning: [unchecked] unchecked case
return (T[]) Arrays.copyOf(elements, size, a.getClass());
^
required: T[]
found: Object[]
만약 메서드 단위가 아닌 번거롭더라도 지역변수를 선언하여 @SuppressWarnings(“unchecked”) 애너테이션을 달아주자. 그럼 다음과 같이 개선을 해줄 수 있다.
public <T> T[] toArray(T[] a) {
if (a.length < size)
// 생성한 배열과 매개변수로 받은 배열의 타입이 모두 T[]로 같으므로
// 올바른 형변환이다.
@SuppressWarnings("unchecked") T[] result =
(T[]) Arrays.copyOf(elementData, size, a.getClass());
return result;
System.arraycopy(elementData, 0, a, 0, size);
if (a.length > size)
a[size] = null;
return a;
}
이제 이 코드는 깔끔하게 컴파일 되고 비검사 경고를 숨기는 범위도 최소로 좁혔다.
@SuppressWarnings(“unchecked”) 애너테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야 한다. 다른 사람이 그 코드를 이해하는 데 도움이 되며, 더 중요하게는, 다른 사람이 그 코드를 잘못 수정하여 타입 안정성을 잃는 상황을 줄여준다.