原文連結 譯者: 沈義揚

異常傳播

有時候，你會想把捕獲到的異常再次丟擲。這種情況通常發生在Error或RuntimeException被捕獲的時候，你沒想捕獲它們，但是宣告捕獲Throwable和Exception的時候，也包括了了Error或RuntimeException。Guava提供了若干方法，來判斷異常型別並且重新傳播異常。例如：

try {
    someMethodThatCouldThrowAnything();
} catch (IKnowWhatToDoWithThisException e) {
    handle(e);
} catch (Throwable t) {
    Throwables.propagateIfInstanceOf(t, IOException.class);
    Throwables.propagateIfInstanceOf(t, SQLException.class);
    throw Throwables.propagate(t);
}

所有這些方法都會自己決定是否要丟擲異常，但也能直接丟擲方法返回的結果——例如，throw Throwables.propagate(t);—— 這樣可以向編譯器宣告這裡一定會丟擲異常。

Guava中的異常傳播方法簡要列舉如下：

Throwables.propagate的用法

模仿Java7的多重異常捕獲和再丟擲

通常來說，如果呼叫者想讓異常傳播到棧頂，他不需要寫任何catch程式碼塊。因為他不打算從異常中恢復，他可能就不應該記錄異常，或者有其他的動作。他可能是想做一些清理工作，但通常來說，無論操作是否成功，清理工作都要進行，所以清理工作可能會放在finallly程式碼塊中。但有時候，捕獲異常然後再丟擲也是有用的：也許呼叫者想要在異常傳播之前統計失敗的次數，或者有條件地傳播異常。

當只對一種異常進行捕獲和再丟擲時，程式碼可能還是簡單明瞭的。但當多種異常需要處理時，卻可能變得一團糟：

@Override public void run() {
    try {
        delegate.run();
    } catch (RuntimeException e) {
        failures.increment();
        throw e;
    }catch (Error e) {
        failures.increment();
        throw e;
    }
}

Java7用多重捕獲解決了這個問題：

    } catch (RuntimeException | Error e) {
        failures.increment();
        throw e;
    }

非Java7使用者卻受困於這個問題。他們想要寫如下程式碼來統計所有異常，但是編譯器不允許他們丟擲Throwable（譯者注：這種寫法把原本是Error或RuntimeException型別的異常修改成了Throwable，因此呼叫者不得不修改方法簽名）：

    } catch (Throwable t) {
        failures.increment();
        throw t;
    }

解決辦法是用throw Throwables.propagate(t)替換throw t。在限定情況下（捕獲Error和RuntimeException），Throwables.propagate和原始程式碼有相同行為。然而，用Throwables.propagate也很容易寫出有其他隱藏行為的程式碼。尤其要注意的是，這個方案只適用於處理RuntimeException 或Error。如果catch塊捕獲了受檢異常，你需要呼叫propagateIfInstanceOf來保留原始程式碼的行為，因為Throwables.propagate不能直接傳播受檢異常。

總之，Throwables.propagate的這種用法也就馬馬虎虎，在Java7中就沒必要這樣做了。在其他Java版本中，它可以減少少量的程式碼重複，但簡單地提取方法進行重構也能做到這一點。此外，使用propagate會意外地包裝受檢異常。

非必要用法：把丟擲的Throwable轉為Exception

有少數API，尤其是Java反射API和（以此為基礎的）Junit，把方法宣告成丟擲Throwable。和這樣的API互動太痛苦了，因為即使是最通用的API通常也只是宣告丟擲Exception。當確定程式碼會丟擲Throwable，而不是Exception或Error時，呼叫者可能會用Throwables.propagate轉化Throwable。這裡有個用Callable執行Junit測試的範例：

public Void call() throws Exception {
    try {
        FooTest.super.runTest();
    } catch (Throwable t) {
        Throwables.propagateIfPossible(t, Exception.class);
        Throwables.propagate(t);
    }

    return null;
}

在這兒沒必要呼叫propagate()方法，因為propagateIfPossible傳播了Throwable之外的所有異常型別，第二行的propagate就變得完全等價於throw new RuntimeException(t)。（題外話：這個例子也提醒我們，propagateIfPossible可能也會引起混亂，因為它不但會傳播引數中給定的異常型別，還丟擲Error和RuntimeException）

這種模式（或類似於throw new RuntimeException(t)的模式）在Google程式碼庫中出現了超過30次。（搜尋’propagateIfPossible[^;]* Exception.class[)];’）絕大多數情況下都明確用了”throw new RuntimeException(t)”。我們也曾想過有個”throwWrappingWeirdThrowable”方法處理Throwable到Exception的轉化。但考慮到我們用兩行程式碼實現了這個模式，除非我們也丟棄propagateIfPossible方法，不然定義這個throwWrappingWeirdThrowable方法也並沒有太大必要。

Throwables.propagate的有爭議用法

爭議一：把受檢異常轉化為非受檢異常

原則上，非受檢異常代表bug，而受檢異常表示不可控的問題。但在實際運用中，即使JDK也有所誤用——如Object.clone()、Integer. parseInt(String)、URI(String)——或者至少對某些方法來說，沒有讓每個人都信服的答案，如URI.create(String)的異常宣告。

因此，呼叫者有時不得不把受檢異常和非受檢異常做相互轉化：

try {
    return Integer.parseInt(userInput);
} catch (NumberFormatException e) {
    throw new InvalidInputException(e);
}

try {
    return publicInterfaceMethod.invoke();
} catch (IllegalAccessException e) {
    throw new AssertionError(e);
}

有時候，呼叫者會使用Throwables.propagate轉化異常。這樣做有沒有什麼缺點？最主要的恐怕是程式碼的含義不太明顯。throw Throwables.propagate(ioException)做了什麼？throw new RuntimeException(ioException)做了什麼？這兩者做了同樣的事情，但後者的意思更簡單直接。前者卻引起了疑問：”它做了什麼？它並不只是把異常包裝進RuntimeException吧？如果它真的只做了包裝，為什麼還非得要寫個方法？”。應該承認，這些問題部分是因為”propagate”的語義太模糊了（用來丟擲未宣告的異常嗎？）。也許”wrapIfChecked”更能清楚地表達含義。但即使方法叫做”wrapIfChecked”，用它來包裝一個已知型別的受檢異常也沒什麼優點。甚至會有其他缺點：也許比起RuntimeException，還有更合適的型別——如IllegalArgumentException。
我們有時也會看到propagate被用於傳播可能為受檢的異常，結果是程式碼相比以前會稍微簡短點，但也稍微有點不清晰：

} catch (RuntimeException e) {
    throw e;
}catch (Exception e) {
    throw new RuntimeException(e);
}

} catch (Exception e) {
 throw Throwables.propagate(e);
}

然而，我們似乎故意忽略了把檢查型異常轉化為非檢查型異常的合理性。在某些場景中，這無疑是正確的做法，但更多時候它被用於避免處理受檢異常。這讓我們的話題變成了爭論受檢異常是不是壞主意了，我不想對此多做敘述。但可以這樣說，Throwables.propagate不是為了鼓勵開發者忽略IOException這樣的異常。

爭議二：異常穿隧

但是，如果你要實現不允許丟擲異常的方法呢？有時候你需要把異常包裝在非受檢異常內。這種做法挺好，但我們再次強調，沒必要用propagate方法做這種簡單的包裝。實際上，手動包裝可能更好：如果你手動包裝了所有異常（而不僅僅是受檢異常），那你就可以在另一端解包所有異常，並處理極少數特殊場景。此外，你可能還想把異常包裝成特定的型別，而不是像propagate這樣統一包裝成RuntimeException。

爭議三：重新丟擲其他執行緒產生的異常

try {
    return future.get();
} catch (ExecutionException e) {
    throw Throwables.propagate(e.getCause());
}

對這樣的程式碼要考慮很多方面：

• ExecutionException的cause可能是受檢異常，見上文”爭議一：把檢查型異常轉化為非檢查型異常”。但如果我們確定future對應的任務不會丟擲受檢異常呢？（可能future表示runnable任務的結果——譯者注：如ExecutorService中的submit(Runnable task, T
  result)方法）如上所述，你可以捕獲異常並丟擲AssertionError。尤其對於Future，請考慮 Futures.get方法。（TODO：對future.get()丟擲的另一個異常InterruptedException作一些說明）
• ExecutionException的cause可能直接是Throwable型別，而不是Exception或Error。（實際上這不大可能，但你想直接重新丟擲cause的話，編譯器會強迫你考慮這種可能性）見上文”用法二：把丟擲Throwable改為丟擲Exception”。
• ExecutionException的cause可能是非受檢異常。如果是這樣的話，cause會直接被Throwables.propagate丟擲。不幸的是，cause的堆疊資訊反映的是異常最初產生的執行緒，而不是傳播異常的執行緒。通常來說，最好在異常鏈中同時包含這兩個執行緒的堆疊資訊，就像ExecutionException所做的那樣。（這個問題並不單單和propagate方法相關；所有在其他執行緒中重新丟擲異常的程式碼都需要考慮這點）

異常原因鏈

Guava提供瞭如下三個有用的方法，讓研究異常的原因鏈變得稍微簡便了，這三個方法的簽名是不言自明的：