本章的第一個例子是：
if(t == null)
throw new NullPointerException();
看起來似乎在傳遞進入一個方法的每個句柄中都必須檢查null（因為不知道調用者是否已傳遞了一個有效的句柄），這無疑是相當可怕的。但幸運的是，我們根本不必這樣做——它屬於Java進行的標准運行期檢查的一部分。若對一個空句柄發出了調用，Java會自動產生一個NullPointerException違例。所以上述代碼在任何情況下都是多余的。
這個類別裡含有一系列違例類型。它們全部由Java自動生成，毋需我們親自動手把它們包含到自己的違例規范裡。最方便的是，通過將它們置入單獨一個名為RuntimeException的基礎類下面，它們全部組合到一起。這是一個很好的繼承例子：它建立了一系列具有某種共通性的類型，都具有某些共通的特征與行為。此外，我們沒必要專門寫一個違例規范，指出一個方法可能會“擲”出一個RuntimeException，因為已經假定可能出現那種情況。由於它們用於指出編程中的錯誤，所以幾乎永遠不必專門捕獲一個“運行期違例”——RuntimeException——它在默認情況下會自動得到處理。若必須檢查RuntimeException，我們的代碼就會變得相當繁復。在我們自己的包裡，可選擇“擲”出一部分RuntimeException。
如果不捕獲這些違例，又會出現什麼情況呢？由於編譯器並不強制違例規范捕獲它們，所以假如不捕獲的話，一個RuntimeException可能過濾掉我們到達main()方法的所有途徑。為體會此時發生的事情，請試試下面這個例子：
//: NeverCaught.java
// Ignoring RuntimeExceptions
public class NeverCaught {
static void f() {
throw new RuntimeException("From f()");
}
static void g() {
f();
}
public static void main(String[] args) {
g();
}
} ///:~
大家已經看到，一個RuntimeException（或者從它繼承的任何東西）屬於一種特殊情況，因為編譯器不要求為這些類型指定違例規范。
輸出如下：
java.lang.RuntimeException: From f()
at NeverCaught.f(NeverCaught.java:9)
at NeverCaught.g(NeverCaught.java:12)
at NeverCaught.main(NeverCaught.java:15)
所以答案就是：假若一個RuntimeException獲得到達main()的所有途徑，同時不被捕獲，那麼當程序退出時，會為那個違例調用printStackTrace()。
注意也許能在自己的代碼中僅忽略RuntimeException，因為編譯器已正確實行了其他所有控制。因為RuntimeException在此時代表一個編程錯誤：
(1) 一個我們不能捕獲的錯誤（例如，由客戶程序員接收傳遞給自己方法的一個空句柄）。
(2) 作為一名程序員，一個應在自己的代碼中檢查的錯誤（如ArrayIndexOutOfBoundException，此時應注意數組的大小）。
可以看出，最好的做法是在這種情況下違例，因為它們有助於程序的調試。
另外一個有趣的地方是，我們不可將Java違例劃分為單一用途的工具。的確，它們設計用於控制那些討厭的運行期錯誤——由代碼控制范圍之外的其他力量產生。但是，它也特別有助於調試某些特殊類型的編程錯誤，那些是編譯器偵測不到的。
