問題

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

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

代碼分析

看ExceptionFilter的代碼：

重點就在圈起來的3個地方：

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

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

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

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

兜底判斷也是有三點：

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

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

3、異常類型是RpcException，不需要處理。?

如果這三者都不滿足，就會到達代碼：

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

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

結(jié)論

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

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

思考

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

個人覺得，依據(jù)是消費者能否反序列化成對應的異常類，消費端有拋出的這個異常類，就能成功反序列化。

1、能拋出受檢異常，那么在方法上必然聲明了拋出該異常，客戶端包里會有該異常類

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

3、如果接口和異常類是在同一個jar吧，說明客戶端包里有異常類

4、jdk自己的異常類，自然是存在的

5、RpcException是dubbo自己的異常類，消費者必然也有

最后

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

最新評論