原文鏈接?譯者: 沈義揚(yáng)

異常傳播

有時(shí)候，你會(huì)想把捕獲到的異常再次拋出。這種情況通常發(fā)生在Error或RuntimeException被捕獲的時(shí)候，你沒(méi)想捕獲它們，但是聲明捕獲Throwable和Exception的時(shí)候，也包括了了Error或RuntimeException。Guava提供了若干方法，來(lái)判斷異常類型并且重新傳播異常。例如：

1

try?{

2	????someMethodThatCouldThrowAnything();

3	}?catch?(IKnowWhatToDoWithThisException e) {

4	????handle(e);

5	}?catch?(Throwable t) {

6	????Throwables.propagateIfInstanceOf(t, IOException.class);

7	????Throwables.propagateIfInstanceOf(t, SQLException.class);

8	????throw?Throwables.propagate(t);

9

}

所有這些方法都會(huì)自己決定是否要拋出異常，但也能直接拋出方法返回的結(jié)果——例如，throw Throwables.propagate(t);—— 這樣可以向編譯器聲明這里一定會(huì)拋出異常。

Guava中的異常傳播方法簡(jiǎn)要列舉如下：

RuntimeException ? propagate(Throwable)	如果Throwable是Error或RuntimeException，直接拋出；否則把Throwable包裝成RuntimeException拋出。返回類型是RuntimeException，所以你可以像上面說(shuō)的那樣寫成throw Throwables.propagate(t)，Java編譯器會(huì)意識(shí)到這行代碼保證拋出異常。
void propagateIfInstanceOf( Throwable, Class<X extends ? Exception>) throws X	Throwable類型為X才拋出
void propagateIfPossible( Throwable)	Throwable類型為Error或RuntimeException才拋出
void ? propagateIfPossible( Throwable, Class<X extends Throwable>) throws X	Throwable類型為X, Error或RuntimeException才拋出

Throwables.propagate的用法

模仿Java7的多重異常捕獲和再拋出

通常來(lái)說(shuō)，如果調(diào)用者想讓異常傳播到棧頂，他不需要寫任何catch代碼塊。因?yàn)樗淮蛩銖漠惓Ｖ谢謴?fù)，他可能就不應(yīng)該記錄異常，或者有其他的動(dòng)作。他可能是想做一些清理工作，但通常來(lái)說(shuō)，無(wú)論操作是否成功，清理工作都要進(jìn)行，所以清理工作可能會(huì)放在finallly代碼塊中。但有時(shí)候，捕獲異常然后再拋出也是有用的：也許調(diào)用者想要在異常傳播之前統(tǒng)計(jì)失敗的次數(shù)，或者有條件地傳播異常。

當(dāng)只對(duì)一種異常進(jìn)行捕獲和再拋出時(shí)，代碼可能還是簡(jiǎn)單明了的。但當(dāng)多種異常需要處理時(shí)，卻可能變得一團(tuán)糟：

01	@Override?public?void?run() {

02

????try?{

03	????????delegate.run();

04	????}?catch?(RuntimeException e) {

05	????????failures.increment();

06	????????throw?e;

07	????}catch?(Error e) {

08	????????failures.increment();

09	????????throw?e;

10

????}

11

}

Java7用多重捕獲解決了這個(gè)問(wèn)題：

1	}?catch?(RuntimeException | Error e) {

2	????failures.increment();

3	????throw?e;

4

}

非Java7用戶卻受困于這個(gè)問(wèn)題。他們想要寫如下代碼來(lái)統(tǒng)計(jì)所有異常，但是編譯器不允許他們拋出Throwable（譯者注：這種寫法把原本是Error或RuntimeException類型的異常修改成了Throwable，因此調(diào)用者不得不修改方法簽名）：

1	}?catch?(Throwable t) {

2	????failures.increment();

3	????throw?t;

4

}

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

總之，Throwables.propagate的這種用法也就馬馬虎虎，在Java7中就沒(méi)必要這樣做了。在其他Java版本中，它可以減少少量的代碼重復(fù)，但簡(jiǎn)單地提取方法進(jìn)行重構(gòu)也能做到這一點(diǎn)。此外，使用propagate會(huì)意外地包裝受檢異常。

非必要用法：把拋出的Throwable轉(zhuǎn)為Exception

有少數(shù)API，尤其是Java反射API和（以此為基礎(chǔ)的）Junit，把方法聲明成拋出Throwable。和這樣的API交互太痛苦了，因?yàn)榧词故亲钔ㄓ玫腁PI通常也只是聲明拋出Exception。當(dāng)確定代碼會(huì)拋出Throwable，而不是Exception或Error時(shí)，調(diào)用者可能會(huì)用Throwables.propagate轉(zhuǎn)化Throwable。這里有個(gè)用Callable執(zhí)行Junit測(cè)試的范例：

01	public?Void call()?throws?Exception {

02

????try?{

03	????????FooTest.super.runTest();

04	????}?catch?(Throwable t) {

05	????????Throwables.propagateIfPossible(t, Exception.class);

06	????????Throwables.propagate(t);

07

????}

08

?

09	????return?null;

10

}

在這兒沒(méi)必要調(diào)用propagate()方法，因?yàn)閜ropagateIfPossible傳播了Throwable之外的所有異常類型，第二行的propagate就變得完全等價(jià)于throw new RuntimeException(t)。（題外話：這個(gè)例子也提醒我們，propagateIfPossible可能也會(huì)引起混亂，因?yàn)樗坏珪?huì)傳播參數(shù)中給定的異常類型，還拋出Error和RuntimeException）

這種模式（或類似于throw new RuntimeException(t)的模式）在Google代碼庫(kù)中出現(xiàn)了超過(guò)30次。（搜索’propagateIfPossible[^;]* Exception.class[)];’）絕大多數(shù)情況下都明確用了”throw new RuntimeException(t)”。我們也曾想過(guò)有個(gè)”throwWrappingWeirdThrowable”方法處理Throwable到Exception的轉(zhuǎn)化。但考慮到我們用兩行代碼實(shí)現(xiàn)了這個(gè)模式，除非我們也丟棄propagateIfPossible方法，不然定義這個(gè)throwWrappingWeirdThrowable方法也并沒(méi)有太大必要。

Throwables.propagate的有爭(zhēng)議用法

爭(zhēng)議一：把受檢異常轉(zhuǎn)化為非受檢異常

原則上，非受檢異常代表bug，而受檢異常表示不可控的問(wèn)題。但在實(shí)際運(yùn)用中，即使JDK也有所誤用——如Object.clone()、Integer. parseInt(String)、URI(String)——或者至少對(duì)某些方法來(lái)說(shuō)，沒(méi)有讓每個(gè)人都信服的答案，如URI.create(String)的異常聲明。

因此，調(diào)用者有時(shí)不得不把受檢異常和非受檢異常做相互轉(zhuǎn)化：

1

try?{

2	????return?Integer.parseInt(userInput);

3	}?catch?(NumberFormatException e) {

4	????throw?new?InvalidInputException(e);

5

}

1

try?{

2	????return?publicInterfaceMethod.invoke();

3	}?catch?(IllegalAccessException e) {

4	????throw?new?AssertionError(e);

5

}

有時(shí)候，調(diào)用者會(huì)使用Throwables.propagate轉(zhuǎn)化異常。這樣做有沒(méi)有什么缺點(diǎn)？最主要的恐怕是代碼的含義不太明顯。throw Throwables.propagate(ioException)做了什么？throw new RuntimeException(ioException)做了什么？這兩者做了同樣的事情，但后者的意思更簡(jiǎn)單直接。前者卻引起了疑問(wèn)：”它做了什么？它并不只是把異常包裝進(jìn)RuntimeException吧？如果它真的只做了包裝，為什么還非得要寫個(gè)方法？”。應(yīng)該承認(rèn)，這些問(wèn)題部分是因?yàn)椤眕ropagate”的語(yǔ)義太模糊了（用來(lái)拋出未聲明的異常嗎？）。也許”wrapIfChecked”更能清楚地表達(dá)含義。但即使方法叫做”wrapIfChecked”，用它來(lái)包裝一個(gè)已知類型的受檢異常也沒(méi)什么優(yōu)點(diǎn)。甚至?xí)衅渌秉c(diǎn)：也許比起RuntimeException，還有更合適的類型——如IllegalArgumentException。
我們有時(shí)也會(huì)看到propagate被用于傳播可能為受檢的異常，結(jié)果是代碼相比以前會(huì)稍微簡(jiǎn)短點(diǎn)，但也稍微有點(diǎn)不清晰：

1	}?catch?(RuntimeException e) {

2	????throw?e;

3	}catch?(Exception e) {

4	????throw?new?RuntimeException(e);

5

}

1	}?catch?(Exception e) {

2	?throw?Throwables.propagate(e);

3

}

然而，我們似乎故意忽略了把檢查型異常轉(zhuǎn)化為非檢查型異常的合理性。在某些場(chǎng)景中，這無(wú)疑是正確的做法，但更多時(shí)候它被用于避免處理受檢異常。這讓我們的話題變成了爭(zhēng)論受檢異常是不是壞主意了，我不想對(duì)此多做敘述。但可以這樣說(shuō)，Throwables.propagate不是為了鼓勵(lì)開(kāi)發(fā)者忽略IOException這樣的異常。

爭(zhēng)議二：異常穿隧

但是，如果你要實(shí)現(xiàn)不允許拋出異常的方法呢？有時(shí)候你需要把異常包裝在非受檢異常內(nèi)。這種做法挺好，但我們?cè)俅螐?qiáng)調(diào)，沒(méi)必要用propagate方法做這種簡(jiǎn)單的包裝。實(shí)際上，手動(dòng)包裝可能更好：如果你手動(dòng)包裝了所有異常（而不僅僅是受檢異常），那你就可以在另一端解包所有異常，并處理極少數(shù)特殊場(chǎng)景。此外，你可能還想把異常包裝成特定的類型，而不是像propagate這樣統(tǒng)一包裝成RuntimeException。

爭(zhēng)議三：重新拋出其他線程產(chǎn)生的異常

1

try?{

2	????return?future.get();

3	}?catch?(ExecutionException e) {

4	????throw?Throwables.propagate(e.getCause());

5

}

對(duì)這樣的代碼要考慮很多方面：

• ExecutionException的cause可能是受檢異常，見(jiàn)上文”爭(zhēng)議一：把檢查型異常轉(zhuǎn)化為非檢查型異?！?。但如果我們確定future對(duì)應(yīng)的任務(wù)不會(huì)拋出受檢異常呢？（可能future表示runnable任務(wù)的結(jié)果——譯者注：如ExecutorService中的submit(Runnable task, T
  result)方法）如上所述，你可以捕獲異常并拋出AssertionError。尤其對(duì)于Future，請(qǐng)考慮?Futures.get方法。（TODO：對(duì)future.get()拋出的另一個(gè)異常InterruptedException作一些說(shuō)明）
• ExecutionException的cause可能直接是Throwable類型，而不是Exception或Error。（實(shí)際上這不大可能，但你想直接重新拋出cause的話，編譯器會(huì)強(qiáng)迫你考慮這種可能性）見(jiàn)上文”用法二：把拋出Throwable改為拋出Exception”。
• ExecutionException的cause可能是非受檢異常。如果是這樣的話，cause會(huì)直接被Throwables.propagate拋出。不幸的是，cause的堆棧信息反映的是異常最初產(chǎn)生的線程，而不是傳播異常的線程。通常來(lái)說(shuō)，最好在異常鏈中同時(shí)包含這兩個(gè)線程的堆棧信息，就像ExecutionException所做的那樣。（這個(gè)問(wèn)題并不單單和propagate方法相關(guān)；所有在其他線程中重新拋出異常的代碼都需要考慮這點(diǎn)）

異常原因鏈

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

Throwable ? getRootCause(Throwable)

List<Throwable> ? getCausalChain(Throwable)

String ? getStackTraceAsString(Throwable)

文章轉(zhuǎn)自?并發(fā)編程網(wǎng)-ifeve.com

總結(jié)

以上是生活随笔為你收集整理的[Google Guava] 1.5-Throwables：简化异常和错误的传播与检查的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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