記一次Dubbo的異常處理過程。
現象：業務團隊報送，服務端定義一個BuinessException，繼承與RunTimeException，服務端執行時拋出該異常，但是客戶端捕捉不到該異常。
記錄：把代碼down下來，開始模擬，發現客戶端收到了Exception，但是卻是RunTimeException，直覺感覺可能是Dubbo的異常處理這一塊兒出了問題，或者是我們的服務端沒有按照一定的規則書寫，看了服務端的接口方法簽名，發現沒有顯示的拋出異常，直覺感覺，如果是沒有顯示的拋出異常，該接口在被Dubbo的動態代理執行invoke方法時，能獲取到ExceptionType嗎？答案，感覺是不能的。
另寫一套代碼保證模擬，竟然是能捕捉到的。為什么呢？下文解釋。
如果獲取不到，Dubbo會怎么處理呢？是不是會new 一個 RunTimeException返回回來呢？我們帶着這些疑問看一下Dubbo的源碼。
代碼就在ExceptionFilter里面，我們打開看一下其實就很清楚了。
這個invoke方法時服務端的代理（Dubbo的動態代理也有點兒意思，改天咱們再寫一個）對象代碼的執行方法，那可以通過method拿到相關異常信息。
1、判斷是否不是RunTimeException 並且 沒有實現GengricService。我們沒有，所以沒有返回我們的BuinessException。
2、如果是check異常直接返回，我們也不是。所以沒有返回我們的BuinessException。
3、
如果方法上有顯示拋出，直接返回，很不幸，我們恰巧少了。
4、如果在同一個jar包里，直接返回（這個就是我們單寫的為什么成功的原因）
5、Jdk的直接返回異常，我們自定義的。
6、Dubbo本身的，直接返回，我們不是。
7、所以，最后我們被new 了一個 RunTimeException 回來。
總結，其實是有日志的，只不過沒有見過，然后也大意忽略了。
解決方案，將沒有添加異常拋出的方法加上（造成上游調用端修改，需要一樣拋出或者try/catch，那也是沒辦法的事，接口本來定義的就不規范）