上下文異常中的上下文屬性

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

我不斷重復同樣的錯誤。

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

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

當查看生產日志時，經常會看到類似"File doesn't exist" ，并且我問自己：什么文件？

它應該在哪里存在？

服務器嘗試使用它做什么？

崩潰前一秒鐘發生了什么？

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

我要么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); }

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

但是我應該。

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

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

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

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

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

我必須更加詳細，并提供更多細節。

我不是一個人犯這個錯誤。 我到處都看到它，這確實使調試變得困難，尤其是在生產中，幾乎不可能立即重現該問題。

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

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

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

上下文異常中的上下文屬性

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。