問(wèn)題

開(kāi)發(fā)過(guò)程中，發(fā)現(xiàn)服務(wù)提供者拋出了自定義的BusinessException，到了消費(fèi)者這邊，卻變成了RuntimeException。

客戶(hù)端這邊有BusinessException這個(gè)類(lèi)，提供者拋出的也是這個(gè)類(lèi)的異常，為什么會(huì)被轉(zhuǎn)成RpcException呢？

代碼分析

看ExceptionFilter的代碼：

重點(diǎn)就在圈起來(lái)的3個(gè)地方：

1、有異常，而且接口不能是GenericService才需要判斷是否需要轉(zhuǎn)換成RuntimeException，不然直接返回result。

2、如果是受檢異常，則不轉(zhuǎn)換，直接返回。

3、如果不是受檢異常，則需要判斷該異常是否在方法上聲明拋出，如果有聲明就不轉(zhuǎn)換，直接返回。

如果不是上面的這三種情況，就會(huì)去到兜底邏輯：

兜底判斷也是有三點(diǎn)：

1、判斷接口和異常是否在一個(gè)jar包中，如果是在一個(gè)jar包，不需要轉(zhuǎn)換成RuntimeException。

2、如果異常是java異常，不需要處理。

3、異常類(lèi)型是RpcException，不需要處理。?

如果這三者都不滿足，就會(huì)到達(dá)代碼：

return new RpcResult(new RuntimeException(StringUtils.toString(exception)));

異常會(huì)被轉(zhuǎn)成字符串，作為RuntimeException的構(gòu)造函數(shù)入?yún)ⅰ?/p>

結(jié)論

由于BusinessException是在一個(gè)通用工具包中，和接口不在一個(gè)jar包中，BusinessException也不是受檢異常，所以不滿足不轉(zhuǎn)換的條件。

要讓提供者拋出的異常不被轉(zhuǎn)成RuntimeException，可以在定義方法的時(shí)候，聲明 throws BusinessException。

思考

為什么dubbo要這樣判斷是否需要轉(zhuǎn)成RuntimeException呢？

個(gè)人覺(jué)得，依據(jù)是消費(fèi)者能否反序列化成對(duì)應(yīng)的異常類(lèi)，消費(fèi)端有拋出的這個(gè)異常類(lèi)，就能成功反序列化。

1、能拋出受檢異常，那么在方法上必然聲明了拋出該異常，客戶(hù)端包里會(huì)有該異常類(lèi)

2、同理，如果不是受檢異常，但是在方法上聲明了，客戶(hù)端也會(huì)有

3、如果接口和異常類(lèi)是在同一個(gè)jar吧，說(shuō)明客戶(hù)端包里有異常類(lèi)

4、jdk自己的異常類(lèi)，自然是存在的

5、RpcException是dubbo自己的異常類(lèi)，消費(fèi)者必然也有

最后

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論