將檢查的異常作為RuntimeException拋出可能會導致什么問題？

Question

我有一段代碼在JSON字符串中編碼某種業務數據：

public String encodeDataAsJsonString(Data data) throws JSONException {
    JSONObject o = new JSONObject();
    o.put("SomeField1", data.getSomeProperty1());
    o.put("SomeField2", data.getSomeProperty2());
    ...
    return o;
}

事情是：

• JSONException是一個已檢查的異常，但是
• 我真的不知道如何在編譯時處理它。 如果真的發生了JSONException，它可能是代碼中的一個錯誤，應該由已經存在的常規“全局未捕獲異常處理程序”（例如這個 ）處理，並且已經執行了所有必要的日志記錄和清理。

因此，我最終在調用方法中執行此操作：

...
try {
    encoded = encodeDataAsJsonString(data);
} catch (JSONException e) {
    throw new RuntimeException(e);
}
...

throws JSONException向調用堆棧中的每個方法添加throws JSONException似乎是一個小惡魔。 但是，它仍然感覺很臟，因此我的問題是：

如果我想要一些特定的檢查異常去“常規未經檢查的異常路由”，是否將它重新拋出為RuntimeException正確使用的習慣用法？

Answer 1

情況非常簡單：如果您的異常沒有業務價值，也就是說，它只是一個失敗，肯定會使用未經檢查的異常。 如果您需要以特定於該異常的方式處理異常，這在大多數情況下意味着處理代碼將涉及業務邏輯，那么使用未經檢查的異常仍然可以，但使用a時至少有一些好處檢查異常。 但是，在任何一種情況下，從JSON API獲得的原始異常都是無用的，它只是公共API設計不良的標志。

作為旁注，有“偷偷摸摸”的習慣用法，它可以讓你在沒有包裝的情況下拋出原始的檢查異常：

public static <R> R sneakyThrow(Throwable t) {
  return UncheckedThrower.<RuntimeException, R>sneakyThrow0(t);
}
@SuppressWarnings("unchecked")
private static <E extends Exception, R> R sneakyThrow0(Throwable t) throws E { throw (E)t; }

不用說，在項目中使用這種方法時應該非常小心。

Answer 2

簡短的回答，是的。

您可以創建自己的異常類（運行時異常的子代）並重新拋出它以便更容易記錄，在必要時捕獲/處理它。 像hibernate這樣的東西通過使用HibernateException來實現，客戶端/調用代碼不會被強制捕獲它，但是當可以使用它完成邏輯/特定於應用程序的特定內容時，它總能捕獲它。

Answer 3

有一個參數只能在Java代碼中使用未經檢查的異常。 如果你想遵循這種方法，那么將你檢查過的異常包裝起來是唯一明智的做法。 FWIW，我多次使用過這種方法，並且它很有用。

即使您不想購買該樣式，將一些已檢查的異常轉換為運行時異常仍然很有用。

Answer 4

我一直這樣做。 是的，這是一個很好的方法。 不，這不是一個骯臟的方法。 就個人而言，我無法檢查例外情況。 我將所有已檢查的異常包裝為運行時異常，而不管它是什么類型的異常。

Answer 5

好吧，如果您不打算在應用程序代碼中處理異常，那么可以將其作為RuntimeException拋出。

我更喜歡使用com.google.common.base.Throwables傳播此內容。

Answer 6

檢查異常是開發人員之間進行通信的一種方式。 檢查過的例外說“處理我”。 如果你知道你做了什么，你可以重新拋出異常（和日志）。

編輯：如在其他答案重寫異常也是很好的建議。