運行時異常表示合同中斷（如NPE），如果代碼沒有錯誤，則永遠不應拋出。它始終指示代碼中的錯誤（與斷言相同，但斷言用於內部類錯誤，而運行時用於類的客戶端錯誤）。爲什麼NumberFormatException是運行時？
運行時異常不應該被捕獲。
另一方面，檢查的異常是簽名的一部分，應該被檢查和處理。它們可能會指示用戶輸入錯誤或外部資源問題（如IOException）。
所有它我不明白爲什麼NumberFormatException是運行時？
爲什麼NumberFormatException是運行時錯誤？那麼如果你有一個用戶輸入一個值的對話框，並且這個值不是一個數字，而是被解析成這樣的話，那麼你就會想知道這個。最好的辦法是例外嗎？也許不是，但它就是這樣。
我認爲這個問題是關於它是RuntimeException的一個子類而不是一個簡單的異常，這不是一個檢查異常。 –
首先，誰告訴你
運行時異常不應該被抓住
不知道很多關於Java的。不要聽他們 - 他們錯了。
NumberFormatException是一個運行時異常：未選中的異常被選中，因爲它們表示編程錯誤。有可能在之前知道（例如）呼叫Integer.parseInt()（例如）字符串是的有效整數，例如，這裏只有一個辦法：
if (str.matches("^\\d{1,8}$") {
int myInt = Integer.parseInt(str); // will never throw NumberFormatException
}
因此，它可以被認爲是一個編程錯誤永遠得到一個 - 程序員選擇不首先檢查。
如果你沒有信心，你將要解析字符串的完整性/質量，很容易趕上：
try {
// parse your string
} catch (NumberFormatException e) {
// do something about it
}
的另一個原因，使其運行時是它不雜波代碼可能不必要的try/catch塊，如果你確信你不會得到一個，例如如果完全信任String數據的來源。
然而，像'URLFormatThingyException'這樣的一些檢查過的異常和你有什麼可以這麼說。總之，這一切都是一團糟。 –
和相同的 - 預先檢查 - 也可以說NPE！ –
絕對！我總是檢查NPE：'if（str！= null && ...）'etc – Bohemian
NumberFormatException擴展IllegalArgumentException。這是運行時異常的原因是，完全可能破壞採用String並返回Number的方法的合約。如果我通過123D並且沒有適當的數據驗證，那麼這將是一個合適的非法論證。
NumberFormatException也可能在解析配置文件時拋出，在這種情況下，這將是一個程序員錯誤。在解析用戶輸入時，通常使用NumberFormat，這會引發選中的ParseException。
配置文件並不總是（或者甚至經常）在程序員的控制下，但我認爲你的觀點是很好的。 Java庫提供不同的API來處理來自可信來源的輸入與來自不可信來源的輸入。 – CurtainDog
是的！幸運的是，找到了這個答案，這就解釋了爲什麼NumberFormat會檢查ParseException，而Integer.parseInt會拋出運行時異常。關於配置文件的好點，那就是我相信它是如何設計和使用的 - 用於用戶輸入的NumerFormat，用於所有其他的Integer.parseInt –
從某種意義上說，NumberFormatException是一個編譯時異常。但不是由Java編譯器引發，而是在程序運行時由格式字符串解析器/編譯器引發。這同樣適用於Pattern和其他正則表達式的使用;你的程序正在運行解析器/編譯器。
沒有代碼，沒有人可以回答。 – RoflcoptrException
就像編譯器不知道某個對象是否爲null時，它不知道被解析的字符串是否實際是一個Number。這是一個只會在運行期間發生的例外。 – asgs
@Roflcoptr：他在問爲什麼NumberFormatException是一個運行時異常，而不是爲什麼他會得到一個。 – Vache