@SuppressWarnings的用途

Question

我沒有理解Java的這個特性。我知道它使得編碼更容易，有時看起來更整潔，但是這是什麼實際使用？相反，我覺得，它更好地顯示警告，因爲將來任何人都可以在修改代碼之前引用它們。這個@SuppressWarnings是否提高了編譯效率？這是根據任何編碼標準嗎？

Answer 1

其他的答案已經解釋用例的@SuppressWarnings很多，但我要強調的是有時你絕對需要使用@SuppressWarnings克服語言本身的限制來看，在這些情況下使用的@SuppressWarnings是絕對合法。

在其他情況下，使用@SuppressWarnings可能會被認爲是有問題的，因爲在這些情況下，您總是可以通過更改代碼來排除警告（儘管顯然它並不總是可以接受的）。

下面是一些常見的情況的時候，你絕對不能讓沒有@SuppressWarnings擺脫警告：實現一個陣列支持泛型集合從類（因爲你無法創建一個通用的陣列）

一個Map到

• 他們的實現（因爲您不能爲不同的地圖類型分配不同的泛型類型參數值）

Answer 2

實際用途是抑制警告。而已。沒有什麼比這更少的了。我認爲這不會影響編譯效率，但絕對不會影響時間效率。

Answer 3

當您處理不支持泛型的遺留代碼（Java < = 1.4）時，這是唯一可行的方法來消除強制轉換警告。

Answer 4

編程時應注意編譯器警告，並在最好的情況下編譯你的代碼，不要有任何警告（當然還有錯誤）。

但有時你不能擺脫警告，你知道代碼是正確的或不能改變。然後，您不希望每次都從編譯器那裏得到錯誤信息。

所以你可以用你提到的命令來壓制它。

Answer 5

在編譯過程中會使用SuppressWarnings（因此，只有編譯器在看到SuppressWarnings註釋時才知道該怎麼做）。

的JavaDoc狀態：

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.

Answer 6

有幾個理由使用@SuppressWarnings，但最有用的案件之一是：

• 有成千上萬的警告現有項目。您希望您的團隊現在關注警告，但您沒有時間修復所有警告。

  該註釋讓您有機會壓制一些無法快速修復並獲得「乾淨」基礎的警告。

  這個乾淨的基礎是必不可少的，因爲沒有人會害怕檢查帶有警告的代碼，但是當代碼庫沒有警告時，他們會害怕，並且團隊中的其他人立即看到某人是什麼時候檢查兩個警告左右的代碼。

• 您正在使用第三方庫，因此您會因爲無法修復的警告而感到惱火，除非在大多數情況下更改lib的代碼。

在我看來，第一個原因是@SuppressWarnings最好的使用案例之一。