java安全編碼指南之:異常處理

簡介

異常是java程序員無法避免的一個話題，我們會有JVM自己的異常也有應用程序的異常，對於不同的異常，我們的處理原則是不是一樣的呢？

一起來看看吧。

異常簡介

先上個圖，看一下常見的幾個異常類型。

所有的異常都來自於Throwable。Throwable有兩個子類，Error和Exception。

Error通常表示的是嚴重錯誤，這些錯誤是不建議被catch的。

注意這裏有一個例外，比如ThreadDeath也是繼承自Error，但是它表示的是線程的死亡，雖然不是嚴重的異常，但是因爲應用程序通常不會對這種異常進行catch，所以也歸類到Error中。

Exception表示的是應用程序希望catch住的異常。

在Exception中有一個很特別的異常叫做RuntimeException。RuntimeException叫做運行時異常，是不需要被顯示catch住的，所以也叫做unchecked Exception。而其他非RuntimeException的Exception則需要顯示try catch,所以也叫做checked Exception。

不要忽略checked exceptions

我們知道checked exceptions是一定要被捕獲的異常，我們在捕獲異常之後通常有兩種處理方式。

第一種就是按照業務邏輯處理異常，第二種就是本身並不處理異常，但是將異常再次拋出，由上層代碼來處理。

如果捕獲了，但是不處理，那麼就是忽略checked exceptions。

接下來我們來考慮一下java中線程的中斷異常。

java中有三個非常相似的方法interrupt，interrupted和isInterrupted。

isInterrupted()只會判斷是否被中斷，而不會清除中斷狀態。

interrupted()是一個類方法，調用isInterrupted(true)判斷的是當前線程是否被中斷。並且會清除中斷狀態。

前面兩個是判斷是否中斷的方法，而interrupt（）就是真正觸發中斷的方法。

它的工作要點有下面4點：

如果當前線程實例在調用Object類的wait（），wait（long）或wait（long，int）方法或join（），join（long），join（long，int）方法，或者在該實例中調用了Thread.sleep（long）或Thread.sleep（long，int）方法，並且正在阻塞狀態中時，則其中斷狀態將被清除，並將收到InterruptedException。
如果此線程在InterruptibleChannel上的I / O操作中處於被阻塞狀態，則該channel將被關閉，該線程的中斷狀態將被設置爲true，並且該線程將收到java.nio.channels.ClosedByInterruptException異常。
如果此線程在java.nio.channels.Selector中處於被被阻塞狀態，則將設置該線程的中斷狀態爲true，並且它將立即從select操作中返回。
如果上面的情況都不成立，則設置中斷狀態爲true。

看下面的例子：

public void wrongInterrupted(){
        try{
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

上面代碼中我們捕獲了一個InterruptedException，但是我們僅僅是打印出了異常信息，並沒有做任何操作。這樣程序的表現和沒有發送一異常一樣，很明顯是有問題的。

根據上面的介紹，我們知道，interrupted()方法會清除中斷狀態，所以，如果我們自身處理不了異常的情況下，需要重新調用Thread.currentThread().interrupt()重新拋出中斷，由上層代碼負責處理，如下所示。

public void correctInterrupted(){
        try{
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

不要在異常中暴露敏感信息

遇到異常的時候，通常我們需要進行一定程度的日誌輸出，從而來定位異常。但是我們在做日誌輸出的時候，一定要注意不要暴露敏感信息。

下表可以看到異常信息可能會暴露的敏感信息：

除了敏感信息之外，我們還要做好日誌信息的安全保護。

在處理捕獲的異常時，需要恢復對象的初始狀態

如果我們在處理異常的時候，修改了對象中某些字段的狀態，在捕獲異常的時候需要怎麼處理呢？

private int age=30;

    public void wrongRestore(){
        try{
            age=20;
            throw new IllegalStateException("custom exception!");
        }catch (IllegalStateException e){
            System.out.println("we do nothing");
        }
    }

上面的例子中，我們將age重置爲20，然後拋出了異常。雖然拋出了異常，但是我們並沒有重置age，最後導致age最終被修改了。

整個restore的邏輯沒有處理完畢，但是我們部分修改了對象的數據，這是很危險的。

實際上，我們需要一個重置：

public void rightRestore(){
        try{
            age=20;
            throw new IllegalStateException("custom exception!");
        }catch (IllegalStateException e){
            System.out.println("we do nothing");
            age=30;
        }
    }

不要手動完成finally block

我們在使用try-finally和try-catch-finally語句時，一定不要在finally block中使用return, break, continue或者throw語句。

爲什麼呢？

根據Java Language Specification（JLS）的說明，finally block一定會被執行，不管try語句中是否拋出異常。

在try-finally和try-catch-finally語句中，如果try語句中拋出了異常R，然後finally block被執行，這時候有兩種情況：

如果finally block正常執行，那麼try語句被終止的原因是異常R。
如果在finally block中拋出了異常S，那麼try語句被終止的原因將會變成S。

我們舉個例子：

public class FinallyUsage {

    public boolean wrongFinally(){
        try{
            throw new IllegalStateException("my exception!");
        }finally {
            System.out.println("Code comes to here!");
            return true;
        }
    }

    public boolean rightFinally(){
        try{
            throw new IllegalStateException("my exception!");
        }finally {
            System.out.println("Code comes to here!");
        }
    }

    public static void main(String[] args) {
        FinallyUsage finallyUsage=new FinallyUsage();
        finallyUsage.wrongFinally();
        finallyUsage.rightFinally();
    }
}

上面的例子中，我們定義了兩個方法，一個方法中我們在finally中直接return,另一方法中，我們讓finally正常執行完畢。

最終，我們可以看到wrongFinally將異常隱藏了，而rightFinally保留了try的異常。

同樣的，如果我們在finally block中拋出了異常，我們一定要記得對其進行捕獲，否則將會隱藏try block中的異常信息。

不要捕獲NullPointerException和它的父類異常

通常來說NullPointerException表示程序代碼有邏輯錯誤，是需要程序員來進行代碼邏輯修改，從而進行修復的。

比如說加上一個null check。

不捕獲NullPointerException的原因有三個。

使用null check的開銷要遠遠小於異常捕獲的開銷。
如果在try block中有多個可能拋出NullPointerException的語句，我們很難定位到具體的錯誤語句。
最後，如果發生了NullPointerException，程序基本上不可能正常運行或者恢復，所以我們需要提前進行null check的判斷。

同樣的，程序也不要對NullPointerException的父類RuntimeException, Exception, or Throwable進行捕捉。

不要throw RuntimeException, Exception, or Throwable

我們拋出異常主要是爲了能夠找到準確的處理異常的方法，如果直接拋出RuntimeException, Exception, 或者 Throwable就會導致程序無法準確處理特定的異常。

通常來說我們需要自定義RuntimeException, Exception, 或者 Throwable的子類，通過具體的子類來區分具體的異常類型。

不要拋出未聲明的checked Exception

一般來說checked Exception是需要顯示catch住，或者在調用方法上使用throws做申明的。

但是我們可以通過某些手段來繞過這種限制，從而在使用checked Exception的時候不需要遵守上述規則。

當然這樣做是需要避免的。我們看一個例子：

private static Throwable throwable;

    private ThrowException() throws Throwable {
        throw throwable;
    }

    public static synchronized void undeclaredThrow(Throwable throwable) {

        ThrowException.throwable = throwable;
        try {
                ThrowException.class.newInstance();
            } catch (InstantiationException e) {
            } catch (IllegalAccessException e) {
        } finally {
            ThrowException.throwable = null;
        }
    }

上面的例子中，我們定義了一個ThrowException的private構造函數，這個構造函數會throw一個throwable,這個throwable是從方法傳入的。

在undeclaredThrow方法中，我們調用了ThrowException.class.newInstance()實例化一個ThrowException實例，因爲需要調用構造函數，所以會拋出傳入的throwable。

因爲Exception是throwable的子類，如果我們在調用的時候傳入一個checked Exception，很明顯，我們的代碼並沒有對其進行捕獲：

public static void main(String[] args) {
        ThrowException.undeclaredThrow(
                new Exception("Any checked exception"));
    }

怎麼解決這個問題呢？換個思路，我們可以使用Constructor.newInstance()來替代class.newInstance()。

try {
        Constructor constructor =
                    ThrowException.class.getConstructor(new Class<?>[0]);
            constructor.newInstance();
        } catch (InstantiationException e) {
        } catch (InvocationTargetException e) {
            System.out.println("catch exception!");
        } catch (NoSuchMethodException e) {
        } catch (IllegalAccessException e) {
        } finally {
            ThrowException.throwable = null;
        }

上面的例子，我們使用Constructor的newInstance方法來創建對象的實例。和class.newInstance不同的是，這個方法會拋出InvocationTargetException異常，並且把所有的異常都封裝進去。

所以，這次我們獲得了一個checked Exception。

來源:https://www.tuicool.com/articles/Q7Zjuar

java安全編碼指南之:異常處理

簡介

異常簡介

不要忽略checked exceptions

不要在異常中暴露敏感信息

在處理捕獲的異常時，需要恢復對象的初始狀態

不要手動完成finally block

不要捕獲NullPointerException和它的父類異常

不要throw RuntimeException, Exception, or Throwable

不要拋出未聲明的checked Exception

面試官：Spring 創建Bean 時是怎樣判斷條件的？

SpringBoot 如何解決項目啓動時初始化資源前言：正文：

Spring Boot 接口如何做限流？面試官問起如何作答閱讀目錄：前言算法介紹滑動窗口漏桶算法令牌桶算法相關變種臨界問題總結

SpringSecurity實戰：分佈式對象“可共享對象” 1. 前言 2. SharedObject SharedObject的註冊 SharedObject的獲取和使用

SpringBoot 輕鬆整合 RocketMq，得勁

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結