最近工作中，發現其他人員開發的模組功能中，在catch語句塊中呼叫了業務方法，目的是當try語句塊中的業務邏輯執行過程中發生異常，再執行catch語句塊中程式碼。

      上述情況的業務場景是這樣的，try語句塊中查詢redis快取（try中查詢redis的程式碼有呼叫了其他開發人員寫的邏輯比較複雜的方法，且多個方法呼叫），catch語句塊中查詢後端資料庫，開發者意圖很明顯，就是如果查詢redis快取出現異常，則查詢後端資料庫，看似很完美的程式碼設計邏輯。但是完美下面也存在一定機率的風險。

       風險分析。暫定該開發人員叫A，如果try語句塊中邏輯比較複雜，且呼叫了其他開發人員（名字為B）的方法，這時候開發人員B在自己的方法中也利用catch捕獲了異常，而不是向上丟擲異常，這時候問題出現了，A寫的程式碼中catch語句塊的業務邏輯有可能不會執行，這就違背了A的設計意圖，也就產生了非常討厭的邏輯bug。開發人員都知道邏輯bug的原因很難找的。

   所以，在日常開發工作，catch語句塊中儘量不要寫業務邏輯，就列印寫異常日誌就可以了。