Allison Anders等人的《四個房間》（1995）。

我不斷重復同樣的錯誤。

因此，該停止并制定規(guī)則以防止這種情況了。

錯誤不是致命的，但很煩人。

當查看生產(chǎn)日志時，經(jīng)常會看到類似"File doesn't exist" ，并且問自己：什么文件？

它應該在哪里存在？

服務器嘗試如何處理它？

崩潰前一秒鐘發(fā)生了什么？

日志中沒有答案，這完全是我的錯。

我要么1）不重新拋出，要么2）在不提供上下文的情況下重新拋出。

兩者都是錯的。

代碼如下所示：

if (!file.exists()) {throw new IllegalArgumentException("File doesn't exist"); }

它也可能看起來像這樣：

try {Files.delete(file); } catch (IOException ex) {throw new IllegalArgumentException(ex); }

這兩個示例都說明了處理涉及異常并報告異常的情況的風格不足。 怎么了 異常消息不夠徹底。 它們根本不包含來自其來源的任何信息。

他們應該這樣看：

if (!file.exists()) {throw new IllegalArgumentException(String.format("User profile file %s doesn't exist",file.getAbsolutePath())); }

第二個示例應如下所示：

try {Files.delete(file); } catch (IOException ex) {throw new IllegalArgumentException(String.format("Can't delete user profile data file %s",file.getAbsolutePath()),ex); }

看到不同？ 這看起來像是冗余代碼，但事實并非如此。 當然，當我編寫所??有這些內(nèi)容時，我并不真正在乎日志和異常。 我不是真的希望這個文件不存在。

但是我應該。

應該有一條規(guī)則：每次我們拋出或重新拋出時，異常消息都必須盡可能詳細地描述問題。

當然，我們不能忘記安全性和冒著將任何敏感信息（例如密碼，信用卡號等）放入異常消息的風險。此外，必須在更高級別上盡可能多地向異常捕獲程序公開這些信息。

拋出異常實際上是將問題升級到更高級別的管理。 想象一下，老板要我安裝新服務器。 幾小時后我回到他身邊說：“我失敗了；我失敗了。 抱歉?！?這聽起來很奇怪。 他會要求更多細節(jié)。 為什么我失敗了？ 到底出了什么問題？ 可以做不同的事情嗎？ 等等。

這樣的代碼實際上是對客戶不尊重的標志：

throw new IllegalArgumentException("File doesn't exist" );

我必須更加詳細，并提供更多細節(jié)。

我不是一個人犯這個錯誤。 我到處都看到它，這確實使調(diào)試困難，尤其是在生產(chǎn)中，幾乎不可能立即重現(xiàn)問題。

因此，請在您的異常消息中更加詳細。 我將在代碼中執(zhí)行同樣的操作：）

還有一件事，然后再走。 在大多數(shù)OOP語言中，未檢查異常是很不幸的 ，這意味著捕獲異常不是強制性操作。 盡管如此，我還是建議您始終捕獲，添加上下文并重新拋出它們。 這似乎是純凈的噪音，但事實并非如此！ 只是使您的方法更小，并確保從它們發(fā)出的所有異常都具有有關其來源的足夠信息。 您將為自己和其他人大有幫助。

翻譯自: https://www.javacodegeeks.com/2015/12/throwing-exception-without-proper-context-bad-habit.html

總結

以上是生活随笔為你收集整理的在没有适当上下文的情况下引发异常是一种不良习惯的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。