Java自定義異常與異常使用的最佳方式
異常的分類
1. 非運行時異常(Checked Exception)
Java中凡是繼承自Exception但不是繼承自RuntimeException的類都是非運行時異常。
2. 運行時異常(Runtime Exception/Unchecked Exception)
RuntimeException類直接繼承自Exception類,稱為運行時異常。Java中所有的運行時異常都直接或間接的繼承自RuntimeException。
Java中所有的異常類都直接或間接的繼承自Exception。
異常的處理
一、對應非運行時異常,必須對其進行處理
處理方式有兩種:
- 使用try…catch…finally語句塊進行捕獲
- 在產生異常的方法所在的方法聲明throws Exception
二、對于運行時異常,可以不對其進行處理
也可以對其進行處理。一般情況下都不對其進行處理。
在使用Java API的方法時會產生異常,由于實際的需要,我們需要創(chuàng)建和使用自定義異常。使用全新的異常類,應用到系統(tǒng)程序中。
在介紹自定義異常時,首要先談談什么要使用自定義異常,使用自定義異常的好處。創(chuàng)建自定義異常是為了表示應用程序的一些錯誤類型,為代碼可能發(fā)生的一個或多個問題提供新的含義;可以顯示代碼多個位置之間的錯誤的相似處,也可區(qū)分代碼運行時可能出現(xiàn)的相似問題的一個或多個錯誤,或給出應用程序中一組錯誤的特殊含義。
應用場景
服務器的基本作用是處理與客戶機的通信,若使用標準Java API(如java.io和java.net包中的類)來編寫服務器,則可使編寫的代碼在多個位置拋出IOException。在設置服務器、等待客戶機連接和獲取通訊流時,可拋出IOException,在通信期間及試圖斷開連接時,也會拋出IOException。簡而言之,服務器的各個部分都是引發(fā)IOException。
對于服務器而言,這樣IOException意義不盡相同。雖然由同一異常類型表示,但與各個異常先關的業(yè)務含義存在差異,報告和恢復操作也不相同。所以,可以將一個異常集與服務器配置和啟動問題關聯(lián),將另一個異常集與客戶機通訊的實際行動關聯(lián),將第三個異常集與服務器關閉任務關聯(lián)。使用自定義異常,可采用對應用程序有意義的方式來靈活地表示錯誤。
為此,我們需要使用自定義異常來定為問題,定位問題與異常實際準確的位置。
自定義異常類過程
1. 多數(shù)情況下
只需要繼承異常類Exception, 經常需要定義一個或多個構造函數(shù),以在對象中存儲錯誤消息。
擴展
類java.lang.Throwable是所有異常類的基類,它包括兩個子類:Exception和Error,Exception類用于描述程序能夠捕獲的異常,如ClassNotFoundException。Error類用于指示合理的應用程序不應該試圖捕獲的嚴重問題,如虛擬機錯誤VirtualMachineError
自定義異常類可以繼承Throwable類或者Exception類,而不要繼承Error類。自定義異常類之間也可以有繼承關系
需要為自定義異常類設計構造方法,以方便構造自定義異常對象。
在繼承任何異常時,將自動繼承Throwable類的一些標準特性,如:
- 錯誤消息
- 棧跟蹤
- 異常包裝
若要在異常中添加附加信息,則可以為類添加一些變量和方法。本例演示的自定義異常沒有按照業(yè)務類型來命名,而是創(chuàng)建一個通用異常類,以retCd來區(qū)別發(fā)生異常的業(yè)務類型與發(fā)生位置,當然對于具體的retCd值,事先必須有具體的規(guī)定或說明。
/**
* 多數(shù)情況下,創(chuàng)建自定義異常需要繼承Exception,本例繼承Exception的子類RuntimeException
* @author Mahc
*
*/
public class CustomerException extends RuntimeException {
private String retCd ; //異常對應的返回碼
private String msgDes; //異常對應的描述信息
public CustomerException() {
super();
}
public CustomerException(String message) {
super(message);
msgDes = message;
}
public CustomerException(String retCd, String msgDes) {
super();
this.retCd = retCd;
this.msgDes = msgDes;
}
public String getRetCd() {
return retCd;
}
public String getMsgDes() {
return msgDes;
}
}
2. 聲明方法拋出自定義異常
為了使用自定義異常,必須通知調用代碼的類:要準備處理這個異常類型。為此,聲明一個或多個方法拋出異常。找到異常發(fā)生點,新建異常并加上關鍵字throw。
public class TestClass {
public void testException() throws CustomerException {
try {
<p> //..some code that throws <span style="font-family:SimSun;">CustomerException</span></p> } catch (Exception e) {
throw new CustomerException("14000001", "String[] strs's length < 4");
}
}
}
3.自定義異常測試操作
public class TestCustomerException {
public static void main(String[] args) {
try {
TestClass testClass = new TestClass();
testClass.testException();
} catch (CustomerException e) {
e.printStackTrace();
System.out.println("MsgDes\t"+e.getMsgDes());
System.out.println("RetCd\t"+e.getRetCd());
}
}
}
以下的自定義異常的最佳實踐,摘自網絡,經過參考擴展使用。
使用異常的最佳實踐
下面的部分我們列出了客戶端代碼處理 API 拋出異常的一些最佳實現(xiàn)方法。
1. 記得釋放資源
如果你正在用數(shù)據(jù)庫或網絡連接的資源,要記得釋放它們。如果你使用的 API 僅僅使用 unchecked exception,你應該用完后釋放它們,使用 try-final。
public void dataAccessCode (){
Connection conn = null;
try{
conn = getConnection ();
..some code that throws SQLException
}catch(SQLException ex){
ex.printStacktrace ();
} finally{
DBUtil.closeConnection (conn);
}
}
class DBUtil{
public static void closeConnection
(Connection conn){
try{
conn.close ();
} catch(SQLException ex){
logger.error ("Cannot close connection");
throw new RuntimeException (ex);
}
}
}
DBUtil 是一個關閉連接的工具類。最重要的部分在于 finally,無論異常發(fā)不發(fā)生都會執(zhí)行。在這個例子中,finally 關閉了連接,如果關閉過程中有問題發(fā)生的話,會拋出一個 RuntimeException。
2. 不要使用異常作控制流程之用
生成?;厮菔欠浅0嘿F的,?;厮莸膬r值是在于調試。在流程控制中,?;厮菔菓摫苊獾?,因為客戶端僅僅想知道如何繼續(xù)。
下面的代碼,一個自定義的異常 MaximumCountReachedException,用來控制流程。
public void useExceptionsForFlowControl () {
try {
while (true) {
increaseCount ();
}
} catch (MaximumCountReachedException ex) {
}
//Continue execution }
public void increaseCount ()
throws MaximumCountReachedException {
if (count >= 5000)
throw new MaximumCountReachedException ();
}
useExceptionsForFlowControl()使用了一個無限的循環(huán)來遞增計數(shù)器,直至異常被拋出。這樣寫不僅降低了代碼的可讀性,也讓代碼變得很慢。記住異常僅用在有異常發(fā)生的情況。
3. 不要忽略異常
當一個 API 方法拋出 checked exception 時,它是要試圖告訴你你需要采取某些行動處理它。如果它對你來說沒什么意義,不要猶豫,直接轉換成 unchecked exception 拋出,千萬不要僅僅用空的{}catch 它,然后當沒事發(fā)生一樣忽略它。
4. 不要 catch 最高層次的 exception
Unchecked exception 是繼承自 RuntimeException 類的,而 RuntimeException 繼承自 Exception。如果 catch Exception 的話,你也會 catch RuntimeException。
try{
..
}catch(Exception ex){
}
上面的代碼會忽略掉 unchecked exception。
5. 僅記錄 exception 一次
對同一個錯誤的棧回溯(stack trace)記錄多次的話,會讓程序員搞不清楚錯誤的原始來源。所以僅僅記錄一次就夠了。
總結:
這里是我總結出的一些異常處理最佳實施方法。我并不想引起關于 checked exception 和 unchecked exception 的激烈爭論。你可以根據(jù)你的需要來設計代碼。我相信,隨著時間的推移,我們會找到些更好的異常處理的方法的。
以上為個人經驗,希望能給大家一個參考,也希望大家多多支持腳本之家.
相關文章
Spring MVC4.1服務器端推送實現(xiàn)過程解析
這篇文章主要介紹了Spring MVC4.1服務器端推送實現(xiàn)過程解析,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2019-11-11
Spring Boot 統(tǒng)一數(shù)據(jù)返回格式的解決方案
統(tǒng)?的數(shù)據(jù)返回格式使? @ControllerAdvice 和 ResponseBodyAdvice 的?式實現(xiàn),下面給大家分享Spring Boot 統(tǒng)一數(shù)據(jù)返回格式的解決方案,感興趣的朋友一起看看吧2024-03-03

