laravel開發大型電商網站之異常設計思路分析

使人討厭的異常

提起異常，你們都很反感，當信心滿滿的寫完一段代碼，刷新頁面發現上面寫着大大的 Exception 是最心煩的時候了。模塊給領導演示的時候，若是報了異常，也是最讓人崩潰的時候了。

在通常的大型網站中，若是擁有異常處理的機制，那麼將會幫助咱們節省不少不須要的工做，具體以下：

什麼是異常

　　異常是運行中超出了你程序預期的一個東西。

場景

例如京東有個 輕鬆購 的功能，當點擊的時候會將該商品自動添加到購物車並生成訂單，而後進行支付，這是一個網絡請求，可是在後端實際執行了一系列的事情（如下操做是簡單舉例子便於說明問題，和真實步驟有差別）

1. 驗證用戶是否登陸
2. 驗證用戶狀態（若是被拉入系統黑名單就不能登陸）
3. 查看訂單中物品是否實時有貨
4. 鎖訂貨物（庫存減小，支付中的貨物數量 + 1）
5. 生成訂單

問題

步驟不少，若是任何一個環節出現問題，就要作響應的處理

1. 用戶沒有登陸就要保存購買信息，並跳轉到登陸頁面
2. 用戶狀態有問題則直接提示禁止繼續購買
3. 若是沒有貨物則跳轉商品頁面
4. 同時購買人太多，本身購買時無貨

處理思路

1. 寫到一個 controller 裏面，順序執行，哪一步出錯直接 return ? 這個 controller 該有多長，代碼徹底不可讀，這是典型面向過程了。
2. 封裝幾個業務方法返回 true false 判斷？比第一個好，可是就像編輯器多了摺疊功能，其實仍是面向過程的思路。

其實咱們能夠定義一個  購買流程的類 和一些異常了。下面是每一個步驟的分析

1. 須要在中間件驗證用戶是否登陸，直接跳轉。
2. 能夠寫個中間件，命名爲 BlacklistMiddleware 專門處理黑名單，也是直接跳轉到禁止界面。
3. 此時其實已經到咱們的業務處理類裏面了，若是無貨，你還會寫跳轉到無貨頁面嗎？顯然這裏不合適了，由於你不知道何時需求變動（能夠繼續購買，只不過等待到貨而已），若是真的跟需求變動來回改核心代碼，累死也寫不完程序了。建一個 NoGoodsException 異常，當你業務處理類發現沒有貨，直接拋出該異常。而後在控制器中 try catch 捕獲該異常進行後續處理，或者使用 App\Exceptions\Handler 進行統一處理。
4. 若是你定義了上面的異常，那麼你就盡情的拋出異常吧，已經有異常程序幫你處理後面的事情。

這樣的好處就是，你的邏輯徹底分離，不要再在業務邏輯代碼裏面考慮如何返回什麼頁面，要跳轉到哪裏，只考慮拋出合適的異常便可，簡單的能夠直接在 App\Exceptions\Handler 定義通用的捕獲異常處理方式，這樣的表現就很是統一了。若是需求高了，能夠 try catch 後再根據狀況再拋更詳細的異常。

 

 

 

記錄異常

對於某些異常，咱們可能須要記錄下來，以便方便發現問題，在 App\Exceptions\Handler 咱們能夠不去記錄一些異常

 

 最後針對不一樣的異常錯誤，能夠作到相關信息記錄，而咱們只須要根據對應的分類找到對應的類庫就能夠

若是有實現疑問或者須要代碼筆記，能夠加入qq羣交流與獲取源碼筆記：647617935