在Spring Filter中丟擲異常的一種辦法

先說辦法，如果看官覺得合適再往下看原理吧

步驟：(

"/filter"

)@restcontroller

public

class

filtercontroller

}

request.
setattribute
("code"
,"***");
request.
getrequestdispatcher
("/filter/login_auth_fail").
forward
(request, response)
;

@controlleradvice public class exphanlder

}

那為什麼沒有成功呢？關鍵在於@controlleradvice只是對controller做了加強，而filter在controller之前進行，故而異常就這樣逃出了咱們的「掌心」。

本文中介紹的辦法，恰是利用了這樣的執行順序，讓異常乖乖地丟擲去：既然filter中不能丟擲，那我先把錯誤資訊記錄下來，把請求**到乙個特定的介面（可認為是乙個「陷阱」），然後在這個介面中利用記錄的錯誤資訊復原乙個異常丟擲即可。

到這，解決辦法的原理已經介紹完了了，後面內容按需**，將和大家一起回顧filter與controller的業務流程。

借用spring 梳理 - filter、interceptor、aop實現與區別 -第二篇中的順序圖：

可以看到，spring在將請求交給controller的介面處理前、後分別呼叫filter鏈中filter的方法對處理進行增強。當prehandle中將異常丟擲時，並沒有到controller，故而@controlleradvice未能攔截該異常。

筆者是在整合shiro時，需要保留原有專案功能：在身份驗證失敗或越權時返回json格式錯誤資訊而遇到了這個問題，因為shiro是基於filter做的攔截，故而需要將filter中的錯誤資訊丟擲。

專案原先的登陸驗證是放在aop做的，而aop也在filter之後進行，關於filter、interceptor、aop及其異常丟擲順序，可以看下這篇文章：spring：過濾器filter、***interceptor、和aop的區別與聯絡