標籤:

如果一個方法拋出了Runtime異常,它的調用方法必須顯式捕獲或者繼續拋出么?

比如方法test() 使用關鍵字throws了Runtime異常或者方法體內throw了Runtime異常,那麼調用者必須用try塊捕獲或者繼續拋出么,還是什麼都不做也可以?


如果按照正常的開發者規範來看 運行時異常多是因為程序有bug導致的(比如不判斷對象是否為空、不做數組邊界檢查、強制轉型的時候期待的值與實際的值不符)

所以拋出運行時異常 也應該基於此類模式做 比如如果發覺一個屬性為空 而你不允許其為空並且自己無法替其容錯 拋出空指針異常即可(或者是等待調用時程序自己拋出)

運行時異常不應該進行捕捉 是期望出現問題時第一時間發覺 但是一旦發生異常導致的崩潰也不是我們期待的結果 所以 捕捉 僅僅是為了讓程序不會崩潰 但是這個代碼沒有任何推進作用 第一時間還是要去修復bug 而不是靠著這個代碼走剩下的邏輯


代碼邏輯上,你可以什麼都不做。一旦拋出異常,就崩潰唄,終止程序執行,或者讓容器、框架等更高層的東東去捕獲異常並處理。

業務邏輯上,一定要做處理。


既然叫Runtime異常說明是在程序運行時才會出現問題,編譯時是不會檢查出來的,所以不加try語句也可以編譯通過,只不過運行的時候拋出異常的話由於沒有catch語句處理,程序會直接崩潰退出。

另外RuntimeException及其子類,叫做非受檢異常 unchecked exception,對應的其他異常叫做受檢異常 checked exception,就是不加try語句塊編譯器是不同意的


究竟是怎樣的函數會聲明拋出 RuntimeException………

通常來說之所以聲明拋出的異常,是為了給上層調用者進行處理,所以一般會是 checked 的。所以說你聲明就是為了告訴我這個函數有 bug………


不是啊。。RuntimeException和普通Exception的區別就是可以不用捕獲,拋出時直接讓程序崩潰掉


個人認為異常是否catch不在於類型,而在於是否應該在這一層邏輯處理,大家都做大家應該做的事,世界就會變得很美好


推薦閱讀:

Python 的異常機制及規範是否相當不人性化?
Go 語言的錯誤處理機制是一個優秀的設計嗎?
各種編程語言中的「錯誤/異常處理」有哪些成熟的,優雅的或是熱門的機制/思想?
為什麼C++中,析構函數、operator delete、以及operator delete []按照慣例不會拋出異常?
c++ 程序運行時異常處理,怎麼定位到出錯代碼行?

TAG:Java | 異常處理 |