코드에서 억제 경고를 사용하는 것이 좋습니다?

내가 사용 @SuppressWarnings("unchecked")하고 @SuppressWarnings("null")경고없이 코드를 컴파일을 수 있도록 대부분의 방법보다하지만 내 의심이. 이 Stackoverflow 질문을 찾았습니다 . Jon Skeet는 이에 대한 답변 을 썼습니다 .

그의 말에 따르면,

때로는 Java generics를 사용하여 원하는 작업을 수행 할 수 없으며 컴파일러가 실제로 수행중인 작업이 실행 시간에 합법적이라는 것을 효과적으로 알려야합니다.

그러나 예외가 발생할 가능성이 있다면 어떨까요? 그렇다면 경고를 억제하지 않는 것이 좋지 않습니까? 문제가 발생할 수있는 장소를 알고 있어야합니까?

또한 누군가 다른 사람이 나중에 내 코드를 수정하고 SuppressWarnings를 제거하지 않고 의심스러운 기능을 추가하면 어떻게됩니까? 어떻게 피할 수 있고 다른 대안이 있습니까?

내가 사용해야 @SuppressWarnings("unchecked")하고 @SuppressWarnings("null")?

업데이트 # 1

이 답변 에 따르면 (아래 주석에서 @gnat이 지적한) 검사되지 않은 유형의 캐스트 는 이러한 경고를 억제해야합니다.

안전하지 않은 타입 캐스트가 필요 없도록 많은 필수 Java 라이브러리가 업데이트 된 적이 없습니다. 다른 더 중요한 경고를보고 수정하려면 해당 경고를 억제해야합니다.

다른 경고를 억제하는 경우 여전히 약간 회색 영역에 있습니다.

업데이트 # 2

당으로 오라클 문서 (또한 다음과 같은 몇 가지 답변 언급) :

스타일의 문제로 프로그래머는 항상 가장 깊은 중첩 요소에이 주석을 사용해야합니다. 특정 메소드에서 경고를 표시하지 않으려면 해당 클래스가 아닌 해당 메소드에 주석을 달아야합니다.

나에게 경고를 억제하는 요점은 프로젝트를 위해 "깨끗한 건강 청구서"를 유지하는 것입니다. 전체 코드베이스가 깨끗하게 컴파일된다는 것을 알고 있다면 누군가가 무언가 잘못했을 때 즉시 경고 메시지가 문제 목록에 표시됩니다. 그런 다음 가짜임을 증명할 수 있으면 오류를 수정하거나 억제 할 수 있습니다.

그러나 시작하기 위해 21 개의 경고가있는 경우 다른 사람이 경고를 표시 할 때 22 번째 경고를 간과 할 가능성이 훨씬 높으며 무해한 지 확인 하지 않습니다 . 즉, 코드베이스에 문제가 발생할 수 있으며 눈치 채지 못할 것입니다.

경고는 유용한 정보 항목입니다. 진실을 말하는 사람들에 유의하고 그렇지 않은 사람들을 걸러 내십시오. 조기 경보 시스템을 잃을 수 있도록 사람들이 두 종류를 섞지 않도록하십시오.

편집하다

장점 이있는 경고 를 억제하는 것은 어리석은 일 이라는 것을 분명히 말해야합니다 . 부정 행위로 얻은 깨끗한 건강 청구서는 가치가 없습니다. 선택이 주어지면 컴파일러가 눈을 감는 대신 항상 발견 한 문제를 해결해야합니다. 그러나 컴파일러가 무언가 문제가 있는지 여부를 확신 할 수없는 영역이 있으며 (Java의 제네릭이 그러한 영역 중 하나입니다), 각 인스턴스를 검토 한 다음이 특정 위치에서 경고를 억제하는 것이 더 나은 선택입니다 이 경고 클래스를 완전히 끄고 잠재적 인 경고를 놓치는 것보다

경고를 억제하는 것은 매우주의해서 수행해야합니다.

경고는 다음을 의미합니다. 컴파일러가 헷갈리는 것을 발견했습니다. 그것이 의미하는 것은 아니다 이다 사기, 그냥 컴파일러에 같습니다. 때로는 완벽하게 괜찮고 경고를주는 코드가 있습니다. 때로는 코드를 약간 수정하여 수정하는 경우가 있습니다. 때때로 컴파일러는 그 목적을 위해 특별히 기능을 가지고 있습니다. 예를 들어

if (x = someFunction ()) { ... }

경고하지만

if ((x = someFunction ())) { ... }

하지 않습니다. 첫 번째 경우 =가 아니라 ==를 의미한다고 가정하는 경고입니다. 두 번째 경우에는 여분의 괄호가 컴파일러에게 "내가하는 일을 알고 있습니다"라고 알리기 때문에 경고가 없습니다. 물론 더 나은

if ((x = someFunction ()) != 0) { ... }

또는 두 줄을 사용합니다.

때로는 코드가 훌륭하지만 경고없이 허용되는 방식으로 코드를 작성할 수없는 경우가 있습니다. 아주 드문 경우이지만 해당 명령문에 대해 경고를 사용하지 않도록 설정 한 후 바로 켜십시오. 이것이 최후의 수단입니다. 그리고 특정 경고 만 비활성화하고 다른 경고는 비활성화하지 않습니다.

그러나 일부 사람들은 합법적 인 경고의 원인을 먼저 찾아 해결하기에는 너무 게으 르기 때문에 경고를 없애기 위해 경고를 비활성화합니다. 또는 경고가없는 코드를 작성하지도 않습니다. 그것은 매우 건강에 해로운 일입니다.

전체 방법에 대한 경고를 억제하는 것이 의심됩니다. 주석과 함께 특정 줄에 대한 경고를 표시하지 않는 것이 좋습니다. 예 :

@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast