異常設計實踐

前段時間結合springcloud閘道器處理異常寫了篇 異常處理實踐，側重於異常的處理。作為強迫症患者，本次撰寫下如何進行異常設計並提供具體的**。

異常結構取決於其應用場景，與其關聯的角色有：使用者、運營人員、技術人員.

由於大部分資料在處理異常時均可以獲取到，因此異常結構可以十分精簡，結構如下：

業務系統和純技術類 「產品」(泛指技術框架、元件等)在異常設計時最大的區別是：技術類產品的使用者都是技術人員。

因此，業務系統可以設計通用的異常類，例如：busines***ception.

code為介面，因mac startuml 介面無法展現方法，這裡用類代替

簡單的提示資訊可以hardcode, 一般提示資訊都存db然後快取在redis，msgdata用於儲存提示資訊中的資料

/**

* 狀態碼
*/public
class
statuscode 

所有列舉類狀態碼例項都需提供獲取狀態碼和提示訊息的方法

/**

* 狀態碼
* 規範異常狀態碼行為
*/public
inte***ce
code 

提供兩個樣例狀態碼，乙個hardcode提示資訊，乙個僅提供狀態碼

/**

* 使用者模組狀態碼
*/public
enum usercode implements code 
usercode(string code, string msg) 
public string getcode() 
public string getmsg() 
}

所有業務系統的基類，繼承自runtimeexception.

statuscode作為異常的私有屬性，提供了設定日誌、提示資訊的方法.

baseexception接收code型別構造器引數，所有列舉型別的狀態碼都可以作為引數

/**

* 異常基類
*/public
class
baseexception
extends
runtimeexception 
public
baseexception(code code, throwable throwable) 
protected statuscode getstatuscode() 
/*** 新增日誌
**@param log 日誌資訊
*@return
*/protected baseexception log(string log) 
/*** 設定提示訊息, 替換列舉類中佔位符
**@param args 引數
*@return
*/protected baseexception msg(object... args) 
/*** 設定異常訊息所需要的資料
**@param msgdata 引數
*@return
*/protected baseexception msgdata(listmsgdata) 
/*** 設定異常訊息所需要的資料
**@param args 引數
*@return
*/protected baseexception msgdata(string... args) 
/*** 格式化模板訊息
**@param messagetemplate 訊息模板
*@param args            引數
*@return
*/public
final
static string format(string messagetemplate, object... args)  catch (exception e) 
}return messagetemplate;}}

/**

* 處理異常demo
*/@test
public
void
handleexceptiondemo()  catch (baseexception e) 
}

logger.warn("發生了***問題，id:{}", "1001");

throw
new ***exception("發生了***問題");

在不具備上述能力時，帶著日誌一起跟隨異常丟擲並持久化。在發生問題時，開發人員不用在各個伺服器上到處找日誌，通過預警郵件就可以獲取全部異常資訊來定位問題.

本文原始碼見github:

Python之異常設計（一）

一 定義 異常分為兩類 一類是自動觸發異常如除零錯誤 另一類是通過raise觸發。二 為什麼要使用異常 當程式執行時，如果檢測到程式錯誤，python就會引發異常，我們可以在程式中使用try語句捕獲異常，並對異常進行處理。如果我們不做異常的捕獲，異常就會一直往上層丟擲，直到頂層python的預設異常...

關於JAVA的異常設計模式

最近在做專案struts spring hibernate的，感覺自己對於設計異常方面有些不是很明白。已經知道這樣的知識 在程式的dao層中不要捕獲異常，而將它拋給service層，然後spring的事務宣告就寫給service層，最終在action中來try catch 業務層service丟擲的...

系統異常設計規範與原則

良好的異常資訊展示，開發運維人員能快速定位問題。響應外部呼叫異常時，應能明確指明是內部異常還是呼叫條件不滿足導至。響應使用者操作異常時，能友好的提示使用者。如何做到以上3點？內部異常 資源環境導致 系統環境異常 資料庫連線超時 第三方服務響應超時 第三方服務錯誤響應 第三方響應結果錯誤 外部傳入引數...