Java圈套之assert症結字詳解

1、概述
 
在C和C++說話中都有assert症結，表現斷言。
在Java中，異樣也有assert症結字，表現斷言，用法和寄義都差不多。

2、語法
 
在Java中，assert症結字是從JAVA SE 1.4 引入的，為了不和老版本的Java代碼中應用了assert症結字招致毛病，Java在履行的時刻默許是不啟動斷言檢討的（這個時刻，一切的斷言語句都 將疏忽！），假如要開啟斷言檢討，則須要用開關-enableassertions或-ea來開啟。

assert症結字語法很簡略，有兩種用法：

1、assert <boolean表達式>
假如<boolean表達式>為true，則法式持續履行。
假如為false，則法式拋出AssertionError，並終止履行。

2、assert <boolean表達式> : <毛病信息表達式>
假如<boolean表達式>為true，則法式持續履行。
假如為false，則法式拋出java.lang.AssertionError，並輸出<毛病信息表達式>。

3、運用實例
 
上面給出一個例子，經由過程例子解釋其用法：

public class AssertFoo {
    public static void main(String args[]) {
        //斷言1成果為true，則持續往下履行
        assert true;
        System.out.println("斷言1沒有成績，Go！");

        System.out.println("\n-----------------\n");

        //斷言2成果為false,法式終止
        assert false : "斷言掉敗，此表達式的信息將會在拋出異常的時刻輸入！";
        System.out.println("斷言2沒有成績，Go！");
    }
}

保留代碼到C:\AssertFoo.java，然後依照上面的方法履行，檢查掌握台輸入成果：

1、編譯法式：
C:\>javac AssertFoo.java

2、默許履行法式，沒有開啟-ea開關：
C:\>java AssertFoo
斷言1沒有成績，Go！

-----------------

斷言2沒有成績，Go！

3、開啟-ea開關，履行法式：
C:\>java -ea AssertFoo
斷言1沒有成績，Go！

-----------------

Exception in thread "main" java.lang.AssertionError: 斷言掉敗，此表達式的信息將
會在拋出異常的時刻輸入！
        at AssertFoo.main(AssertFoo.java:10)

4、圈套
 
assert症結字用法簡略，然則應用assert常常會讓你墮入愈來愈深的圈套中。應防止應用。筆者經由研討，總結了以下緣由：

1、assert症結字須要在運轉時刻顯式開啟能力失效，不然你的斷言就沒有任何意義。而如今主流的Java IDE對象默許都沒有開啟-ea斷言檢討功效。這就意味著你假如應用IDE對象編碼，調試運轉時刻會有必定的費事。而且，關於Java Web運用，法式代碼都是安排在容器外面，你沒法直接去掌握法式的運轉，假如必定要開啟-ea的開關，則須要更改Web容器的運轉設置裝備擺設參數。這對法式的移 植和安排都帶來很年夜的未便。

2、用assert取代if是圈套之二。assert的斷定和if語句差不多，但二者的感化有著實質的差別：assert症結字本意上是為測試 調試法式時應用的，但假如不當心用assert來掌握了法式的營業流程，那在測試調試停止後去失落assert症結字就意味著修正了法式的正常的邏輯。

3、assert斷言掉敗將面對法式的加入。這在一個臨盆情況下的運用是毫不能容忍的。普通都是經由過程異常處置來處理法式中潛伏的毛病。然則應用斷言就很風險，一旦掉敗體系就掛了。

 
5、對assert的思慮
 
assert既然是為了調試測試法式用，不在正式臨盆情況下用，那應當斟酌更好的測試JUint來取代其做用，JUint絕對assert症結的所供給的功效是有過之而無不及。固然完整可以經由過程IDE debug來停止調試測試。在此看來，assert的前程一片陰暗。

是以，應該防止在Java中應用assert症結字，除非哪一天Java默許支撐開啟-ea的開關，這時候候可以斟酌。比較一下，assert能給你帶來若干利益，若干費事，這是我們選擇能否應用的的准繩。

============================================================
comment：
反過去說，在某些開源組件中，好比validator、junit中，斷定進程似乎應用了斷言作風，很有能夠應用了年夜量的斷言，但筆者在沒看源碼之前不克不及肯定。
假如是開辟階段的簡略測試，junit就是一個便捷強悍的對象，沒有來由本身寫斷言而不去用它。

============================================================
comment：
起首可以用在單位測試代碼中。junit侵入性是很強的，假如全部工程年夜量的代碼都應用了junit，就難以去失落或許是選擇別的一個框架。假如單位測試代碼 許多，而且想復用這些單位測試案例，應當選擇assert而不是junit，便於應用其余單位測試框架，好比TestNG。同理正式的功效代碼基本就不該 該湧現Junit，應當應用assert.

assert重要合適在基類，框架類，接口類，焦點代碼類，對象類中。換言之，當你的代碼的挪用者是別的一個法式員寫得營業代碼，或許是別的一個子體系時，就很有需要應用它。好比你做了一個疾速排序的算法

public static List<int> quickSort(List<int> list){
  assert list != null;
  // 請求暫時空間
  //開端排序
  for(int i : list){
      //
  }
}

這類情形下，假如不檢討傳入參數的准確性，會拋出一個莫明其妙的空指針毛病。你的挪用者能夠其實不清晰你代碼的細節，在一個體系的深處調試一個空指針毛病是很糟蹋時光的。就應當直接明白的告知你的挪用者是傳入的參數有成績。不然他會疑惑你的代碼有BUG。應用assert可以免兩個法式員之間相互責備對方寫的代碼有成績。

assert實用那些你曉得詳細是甚麼毛病，你和你的挪用者曾經商定應當由你的挪用者去消除或檢討的毛病。你經由過程一個斷言告知你的挪用者。assert不實用那些內部體系形成的毛病，好比用戶輸出數據的毛病，某個內部文件格局毛病。這些毛病不是你的挪用者而是用戶形成的，乃至於不屬於異常，由於湧現輸出毛病和文件格局毛病是常常的，這些毛病應當由營業代碼去檢討。

assert比擬合適於被頻仍挪用的 基類，框架代碼，對象類，焦點代碼，接口代碼中，這恰是它在運轉時被去失落的緣由。測試代碼應當在測試階段開啟-ea參數，便於對體系深處的焦點代碼做細心的測試。

Java較少應用assert的緣由是Java有很完全的OO系統，強迫類型轉換湧現得較少，所以不須要相似c那樣須要頻仍的檢討指針的類型能否准確，指針能否為空。同時Java也很少直接收理內存或緩沖區，所以不須要頻仍的檢討傳入的緩沖區能否為空或許是曾經越界。

但應用好assert有助於進步框架代碼的准確性和削減框架代碼的應用者的調試時光。

===============================================================
comment：
assert要到達的目標是讓法式員便利的發明本身的邏輯毛病，而且不影響法式的效力。assert所發明的毛病，是完整不該該湧現的，是不克不及用異常取代的。異常，那是體系所許可的，或許是體系弗成控的“毛病”，它不是法式員的邏輯成績。

assert應當是開辟階段翻開，而在宣布後封閉。