Java中如何對異常進行處理

這篇文章將為大家詳細講解有關Java中如何對異常進行處理，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

目前創(chuàng)新互聯(lián)公司已為成百上千的企業(yè)提供了網站建設、域名、網頁空間、網站托管、服務器租用、企業(yè)網站設計、滄源網站維護等服務，公司將堅持客戶導向、應用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

什么是異常？總結為一句話就是：程序在執(zhí)行過程中產生的異常情況。當某些事情出現(xiàn)了錯誤異常就會發(fā)生，比如打開一個并不存在的文件、嘗試在一個為null的對象上調用方法等等，都會發(fā)生異常。

異常是不可預知的，可是一旦它發(fā)生了就需要進行異常處理，可謂知錯就改善莫大焉！異常處理是一種錯誤處理機制，如果你不對異常做任何處理，異常將會導致應用程序崩潰。

一旦你選擇了進行處理異常，也就意味著你承認問題的發(fā)生，采用必要要的措施去讓應用程序從錯誤中恢復，從而讓業(yè)務繼續(xù)進行，阻止應用程序崩潰。

實際上異常處理并不是處理問題的唯一一種方式，如今的高級語言一般都有異常處理機制，但比較古老的如C語言是通過返回錯誤碼的方式來處理異常的。比如數(shù)組越界比較常用的返回值是-1。

這種方式的優(yōu)點是代碼邏輯易于推理，沒有中斷和代碼跳轉。另一方面，這種處理方式鼓勵函數(shù)的調用者總是檢查返回的錯誤碼。但是這種檢查容易造成代碼污染，導致代碼的可讀性和可維護性降低。

錯誤代碼的另一個嚴重的缺點是缺乏上下文信息，你可能知道錯誤碼“-5”代表找不到文件，但究竟找不到哪個文件呢！錯誤碼就無法表述了。

錯誤代碼一般用于面向過程的語言，對面向對象的高級語言，有些場景是無能為力的，比如構造函數(shù)異常，是無法返回錯誤碼的。

當異常被拋出時，應用程序的流程就會被中斷，如果沒能及時處理異常，應用程序將崩潰。用戶將看到異常信息，但那些信息大多他們是看不懂的，這將是一個很糟糕的用戶體驗，實際上異常信息還可以包裝成非常友好的提示。

所以必須進行異常處理，哪怕是為了提高用戶體驗、記錄問題日志、優(yōu)雅地退出應用程序等。

我們可以使用代碼塊(try...catch...)來進行異常處理，當發(fā)生異常，通過try執(zhí)行代碼，如果發(fā)生異常，應用程序的流程將轉移到catch中，catch捕捉到異常并進行必要的處理。

以上表述的異常處理原理對初學者依然比較抽象，我們來舉個例子

package com.zqf;

public class App
{
    public static void main(String[] args){
        System.out.println("First line");
        System.out.println("Second line");
        System.out.println("Third line");
        //初始化具有3個元素的素組
        int[] myIntArray = new int[]{1, 2, 3};
        print4thItemInArray(myIntArray);
        System.out.println("Fourth line");
        System.out.println("Fith line");
    }

    private static void print4thItemInArray(int[] arr) {
        //獲取第4個(下標3)元素，因為沒有所以拋出異常
        System.out.println(arr[3]);
        System.out.println("Fourth element successfully displayed!");
    }
}

分析下這個程序，在main中初始化有3個元素的數(shù)組，把這個數(shù)組傳遞給私有方法print4thItemInArray，在print4thItemInArray中試圖獲取數(shù)組的第4個元素，由于沒有第4個元素將拋出“ArrayIndexOutOfBoundsException”異常，應用程序只會打印到“Third line”。

執(zhí)行應用輸出結果如下

First line 

Second line 

Third line 

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 3

   at com.zqf.App.print4thItemInArray(App.java:20) 

   at com.zqf.App.main(App.java:14) 

Process finished with exit code 1

現(xiàn)在我們修改下，增加異常處理

package com.zqf;

public class App {
    public static void main(String[] args) {
        System.out.println("First line");
        System.out.println("Second line");
        System.out.println("Third line");
        //初始化具有3個元素的素組
        int[] myIntArray = new int[]{1, 2, 3};

        try {//捕捉異常
            print4thItemInArray(myIntArray);
        }catch (ArrayIndexOutOfBoundsException ex){//異常處理
            System.out.println("Have no four items!");
        }
        System.out.println("Fourth line");
        System.out.println("Fith line");
    }

    private static void print4thItemInArray(int[] arr) {
        //獲取第4個(下標3)元素，因為沒有所以拋出異常
        System.out.println(arr[3]);
        System.out.println("Fourth element successfully displayed!");
    }
}

現(xiàn)在運行看看輸出

First line 

Second line 

Third line                

Have no four items! 

Fourth line 

Fith line

實際上這次的異常依然會發(fā)生，因為第4個元素的確不存在，所以在"Fourth element successfully displayed!"輸出之前就拋出了異常，中斷執(zhí)行流程，但流程跳轉到catch語句塊了，catch只打印了一條“Have no four items”，繼續(xù)向下執(zhí)行。

在Java中，所有的異常都有一個共同的祖先Throwable，它有2個子類：Exception(異常)和Error(錯誤)，它們又各自有大量的子類。Exception(異常)和Error(錯誤)的共性和區(qū)別：兩者都可以被捕捉，但前者可以被應用程序本身處理，后者是嚴重的，是無法恢復處理的。

我們經常在try語句塊使用資源，比如InputStream，使用完后需要關閉。經常犯的錯誤是在try語句塊中關閉資源。如

public void doNotCloseResourceInTry() {
    FileInputStream inputStream = null;
    try {
        File file = new File("./tmp.txt");
        inputStream = new FileInputStream(file);

        // 使用inputStream讀取文件

        // 不要這樣做
        inputStream.close();
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    }
}

這種方式看似非常完美，不會有異常拋出，所有的語句在try中執(zhí)行，關閉IputStream釋放資源。但試想一下：如果在“inputStream.close()”語句之前就拋出異常，會怎樣呢？正常的流程會被中斷并跳轉，導致InputStream根本沒關閉。

因此，應該把清理資源的代碼放在finally或try-with-resource語句中。不管是正常執(zhí)行完try語句塊，還是異常處理完畢，都會執(zhí)行finally語句塊，而你需要確保在finally關閉所有打開的資源。

public void doNotCloseResourceInTry() {
    FileInputStream inputStream = null;
    try {
        File file = new File("./tmp.txt");
        inputStream = new FileInputStream(file);

        // 使用inputStream讀取文件
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    } finally {
        if (inputStream != null) {
            try {
                inputStream.close();
            } catch (Exception e) {
                log.error(e);
            }
        }
    }
}

在JDK7引入了try-with-resource的語法，簡單來說當一個資源對象(如InputSteam對象)實現(xiàn)了AutoCloseable接口，那么就可以在try關鍵字后的括號里創(chuàng)建實例，當try-catch語句塊執(zhí)行完畢后，會自動關閉資源，代碼也會簡潔許多。如下

public void doNotCloseResourceInTry() {
    File file = new File("./tmp.txt");
    try (FileInputStream inputStream = new FileInputStream(file)) {

        // 使用inputStream讀取文件
    } catch (FileNotFoundException e) {
        log.error(e);
    } catch (IOException e) {
        log.error(e);
    }
}

你拋出的異常越具體越好，不熟悉你代碼的同事或者幾個月之后的你，可能需要調用你這些方法并進行異常處理，所以盡可能多的提供信息，讓你的API更容易理解，比如能用NumberFormatException就不要用 IllegalArgumentException，絕對避免直接使用不具體的Exception類。

//不建議
public void doNotDoThis() throws Exception { ... }
//建議
public void doThis() throws NumberFormatException { ... }

只要你在方法聲明異常，就需要做好Javadoc的注釋。這點和上一條最佳實踐有相同的目標：提供給調用者盡可能多的信息，便于避免異常或進行異常處理。所以請確保你在Javadoc中添加了"@throws"聲明，并且描述了造成異常的情況。

/**
* This method does something extremely useful ...
*
* @param input
* @throws MyBusinessException if ... happens
*/
public void doSomething(String input) throws MyBusinessException { ... }

這條最佳實踐和前面兩條有點相似，但這條提供的信息不單是給方法調用者看的，而更多的是為了給記錄日志或監(jiān)控工具提供的，便于排查異常。實際上一般的異常類名就已經描述了問題的類型，你不必提供大量的附加信息，簡潔凝練即可。比如NumberFormatException，當java.lang.Long構造函數(shù)拋出異常時會提供一句簡短且清晰的文本來描述。

try {
 new Long("xyz");
} catch (NumberFormatException e) {
 log.error(e);
}

NumberFormatException 的名字就已經告訴你異常的種類，它攜帶的信息僅告訴你提供的字符串會導致異常，但如果異常名字不能表達異常種類，就需要提供更多的信息。上述的異常信息如下

17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"

如果你仔細看下JDK的源碼，就會清楚java.lang.Long在構造器中做了各種校驗，當某些校驗失敗會調用NumberFormatException.forInputString，而靜態(tài)方法forInputString會把java.lang.Long的構造參數(shù)格式化后再構造一個新的NumberFormatException實例并拋出

/**
 * Factory method for making a <code>NumberFormatException</code>
 * given the specified input which caused the error.
 *
 * @param   s   the input causing the error
 */
static NumberFormatException forInputString(String s) {
    return new NumberFormatException("For input string: \"" + s + "\"");
}

很多IDE都會幫助你進行最佳實踐，如果你先捕捉父類異常再捕捉子類異常，它們會告訴你后面的代碼不可到達或者警告已經被捕捉，因為是按照catch在在代碼中順序執(zhí)行的。

所以如果先捕捉IllegalArgumentException，將不能捕捉到其子類NumberFormatException，因此最佳時間是總是先捕捉更多信息的異常(子類)，再捕捉父類。如

public void catchMostSpecificExceptionFirst() {
    try {
        doSomething("A message");
    } catch (NumberFormatException e) {
        log.error(e);
    } catch (IllegalArgumentException e) {
        log.error(e)
    }
}

從Java異常體系的圖中可知，Throwable是所有異常(Exception)和錯誤(Error)的祖先，Throwable是可以被捕捉，但請不要捕捉。如果你捕捉了Throwable，那么不僅僅是捕捉了異常，還捕捉了錯誤。但錯誤是無法恢復，它是被JVM拋出的嚴重錯誤，應用程序對這類錯誤是無能為力的。

//不要捕捉Throwable
public void doNotCatchThrowable() {
    try {
        // do something
    } catch (Throwable t) {
        // don't do this!
    }
}

你是否記得曾幾何時，在分析bug時遇到代碼只執(zhí)行了前半部分，但卻不知為何。有些開發(fā)者經常捕捉了異常，但憑經驗認為異常決定不可能發(fā)生，導致沒有做異常處理。

public void doNotIgnoreExceptions() {
    try {
        // do something
    } catch (NumberFormatException e) {
        // this will never happen,I'm sure!!
    }
}

實際上在大多數(shù)情況下它都發(fā)生了，因為隨著時間和業(yè)務邏輯的變更，try代碼塊的內容變更了，導致了異常發(fā)生，而你的自信不僅害了你也害了后來人。建議catch中至少要留一條日志，來告知異常問題，方便排查。

public void logAnException() {
    try {
        // do something
    } catch (NumberFormatException e) {
        log.error("This should never happen: " 
         + e + ",but I get a mistake!");
    }
}

“不要在僅僅記錄日志后向上拋出異?！保@是最佳實踐中最容易被忽視的一條。你會發(fā)現(xiàn)在大量的代碼片段，甚至類庫中經常捕捉異常、記錄日志，然后拋出異常。

try {
 new Long("xyz");
} catch (NumberFormatException e) {
 log.error(e);
 throw e;
}

直觀的感覺是記錄異常，然后拋出異常讓調用者可以恰當?shù)奶幚恚粋€異常多處日志記錄，會讓人迷惑，請參考第4條最佳實踐：簡潔凝練。

17:44:28,945 ERROR TestExceptionHandling:65 - java.lang.NumberFormatException: For input string: "xyz"
Exception in thread "main" java.lang.NumberFormatException: For input string: "xyz"
 at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
 at java.lang.Long.parseLong(Long.java:589)
 at java.lang.Long.(Long.java:965)
 at com.stackify.example.TestExceptionHandling.logAndThrowException(TestExceptionHandling.java:63)
 at com.stackify.example.TestExceptionHandling.main(TestExceptionHandling.java:58)

如果你真的需要給調用者提供更多信息，可以參考下一條最佳實踐：包裝異常。

比較可取的做法是捕捉到標準異常，根據實際業(yè)務自定義包裝異常再向上拋出。在包裝異常時通常把原始異常作為構造參數(shù)傳進來，否則會丟失棧的跟蹤信息，造成分析困難。

public void wrapException(String input) throws MyBusinessException {
 try {
  // do something
 } catch (NumberFormatException e) {
  throw new MyBusinessException("A message that describes the error.", e);
 }
}

關于Java中如何對異常進行處理就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。

網站題目：Java中如何對異常進行處理
網頁網址：http://bm7419.com/article2/pdheoc.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供網站制作、網站設計、ChatGPT、網站策劃、靜態(tài)網站、服務器托管

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)