5
Java의이 기능을 이해하지 못했습니다. 코딩이 더 쉬워지고 때로는 더 깔끔하게 보일 수도 있지만 실제 사용은 무엇입니까? 반대로 나는 경고를 표시하는 것이 좋습니다. 앞으로 코드를 수정하기 전에 경고를 표시하는 것이 좋습니다. @SuppressWarnings가 효율성을 높이는가? 또는 코딩 표준에 따른 것입니까?@SuppressWarnings의 사용법은 무엇입니까
A
답변
5
다른 답변은 이미 @SuppressWarnings 많은의 사용 사례를 설명했다,하지만 난 때때로 당신이 절대적으로 언어 자체의 한계를 극복하기 위해 @SuppressWarnings를 사용할 필요가 있다는 점을 강조하고 싶다, 그리고 @SuppressWarnings 이러한 경우 사용에 절대적으로 합법적이다 .
다른 경우에는 @SuppressWarnings을 사용하는 것이 의심 스러울 수 있습니다. 이러한 경우 코드를 변경하여 항상 경고를 없앨 수 있기 때문입니다 (분명히 항상 받아 들일 수있는 것은 아니지만).에 클래스에서
Map을 (당신은 일반적인 배열을 만들 수 없기 때문에) 배열 백업 일반적인 수집을 구현
- : 여기 몇 가지 일반적인 당신이 절대적으로
@SuppressWarnings없이 경고를 제거 할 수없는 경우입니다 (다른 맵 엔트리에 제네릭 타입 매개 변수의 다른 값을 할당 할 수 없기 때문에)
1
실제 사용은 경고를 억제하는 것입니다. 그게 전부 야. 덜 아무것도, 아무것도 더. 컴파일 효율에 영향을 미치지는 않겠지 만 시간 효율성은 떨어지지 않습니다.
3
캐스트 경고를 제거 할 수있는 유일한 방법은 제네릭 (Java < = 1.4)을 지원하지 않는 레거시 코드를 다룰 때입니다.
9
프로그래밍하는 동안 컴파일러 경고 및 최상의 경우 경고없이 (물론 오류없이) 컴파일해야합니다.
가끔은 경고를 없앨 수 없으며 코드가 정확하거나 변경 될 수 없다는 것을 알고 있습니다. 그렇다면 컴파일러에서 매번 귀찮은 일이 생기고 싶지는 않습니다.
그래서 당신이 언급 한 명령으로 그것을 억제 할 수 있습니다.
1
컴파일 중에는 SuppressWarnings을 사용해야합니다 (따라서 컴파일러 만 SuppressWarnings 주석을 볼 때 수행 할 작업을 알고 있습니다).
JavaDoc 상태 : @SuppressWarnings하지만 가장 유용한 사례 중 하나를 사용하는 몇 가지 이유가 있습니다
The set of warnings that are to be suppressed by the compiler in the annotated element. Duplicate names are permitted. The second and successive occurrences of a name are ignored. The presence of unrecognized warning names is not an error: Compilers must ignore any warning names they do not recognize. They are, however, free to emit a warning if an annotation contains an unrecognized warning name.
1
은 다음과 같습니다
- 경고가 수천 기존 프로젝트를 가졌어요. 팀은 현재 경고에 신경을 쓰고 싶지만 모든 경고를 고칠 시간은 없습니다.
주석은 신속하게 해결할 수없는 경고를 억제하고 "깨끗한"기반을 확보 할 수있는 기회를 제공합니다.
수천 명이있을 때 경고가있는 코드를 확인하는 것을 두려워하지 않으므로 아무도 염려하지 않을 것이므로 코드베이스가 경고없이 실행되고 다른 사람이 누구인지 즉시 확인해야하므로 2 경고 또는 너무 코드를 확인하십시오.
- 타사 라이브러리를 사용하고 있으므로 대부분의 경우 원하지 않는 lib 코드를 변경하는 경우를 제외하고는 해결할 수없는 경고로 짜증이납니다.
제 생각에는 첫 번째 이유는 @SuppressWarnings의 가장 좋은 사용 사례 중 하나입니다.
'SuppressWarnings'는 제네릭 지원 또는 캐스트 경고에만 사용되지 않습니다. –
그들이 누구인가라고 :)? –
게시물을 다시 읽으십시오. –