問題一、
在實際使用zuul發現一個問題，在路由地址無法抵達時，zuul拋出 Filter threw Exception ，屏蔽了實際錯誤。
通過閱讀源碼可得，zuul會拋出ZuulException異常，將RunTimeException封裝在內部。
需要使用throwable攔截器捕獲。
重寫findZuulException方法
問題二、
上面代碼源自com.netflix.zuul.http.ZuulServlet的service方法實現，它定義了Zuul處理外部請求過程時，各個類型過濾器的執行邏輯。從代碼中我們可以看到三個try-catch塊，它們依次分別代表了pre、route、post三個階段的過濾器調用，在catch的異常處理中我們可以看到它們都會被error類型的過濾器進行處理（之前使用error過濾器來定義統一的異常處理也正是利用了這個特性）；error類型的過濾器處理完畢之后，除了來自post階段的異常之外，都會再被post過濾器進行處理。而對於從post過濾器中拋出異常的情況，在經過了error過濾器處理之后，就沒有其他類型的過濾器來接手了，這就是使用之前所述方案存在不足之處的根源。
回想一下之前實現的兩種異常處理方法，其中非常核心的一點，這兩種處理方法都在異常處理時候往請求上下文中添加了一系列的error.*參數，而這些參數真正起作用的地方是在post階段的SendErrorFilter，在該過濾器中會使用這些參數來組織內容返回給客戶端。而對於post階段拋出異常的情況下，由error過濾器處理之后並不會在調用post階段的請求，自然這些error.*參數也就不會被SendErrorFilter消費輸出。所以，如果我們在自定義post過濾器的時候，沒有正確的處理異常，就依然有可能出現日志中沒有異常並且請求響應內容為空的問題。我們可以通過修改之前ThrowExceptionFilter的filterType修改為post來驗證這個問題的存在，注意去掉try-catch塊的處理，讓它能夠拋出異常。
解決上述問題的方法有很多種，比如最直接的我們可以在實現error過濾器的時候，直接來組織結果返回就能實現效果，但是這樣的缺點也很明顯，對於錯誤信息組織和返回的代碼實現就會存在多份，這樣非常不易於我們日后的代碼維護工作。所以為了保持對異常返回處理邏輯的一致，我們還是希望將post過濾器拋出的異常能夠交給SendErrorFilter來處理。
在前文中，我們已經實現了一個ErrorFilter來捕獲pre、route、post過濾器拋出的異常，並組織error.*參數保存到請求的上下文中。由於我們的目標是沿用SendErrorFilter，這些error.*參數依然對我們有用，所以我們可以繼續沿用該過濾器，讓它在post過濾器拋出異常的時候，繼續組織error.*參數，只是這里我們已經無法將這些error.*參數再傳遞給SendErrorFitler過濾器來處理了。所以，我們需要在ErrorFilter過濾器之后再定義一個error類型的過濾器，讓它來實現SendErrorFilter的功能，但是這個error過濾器並不需要處理所有出現異常的情況，它僅對post過濾器拋出的異常才有效。根據上面的思路，我們完全可以創建一個繼承自SendErrorFilter的過濾器，就能復用它的run方法，然后重寫它的類型、順序以及執行條件，實現對原有邏輯的復用，具體實現如下：
新增一個ErrorFilterExtFilter，專門過濾FilterType = POST的錯誤
https://www.cnblogs.com/duanxz/p/7543040.html
