Unchecked Exceptions — The Controversy
Because the Java programming language does not require methods to catch or to specify unchecked exceptions (RuntimeException, Error, and their subclasses), programmers may be tempted to write code that throws only unchecked exceptions or to make all their exception subclasses inherit from RuntimeException. Both of these shortcuts allow programmers to write code without bothering with compiler errors and without bothering to specify or to catch any exceptions. Although this may seem convenient to the programmer, it sidesteps the intent of the catch or specify requirement and can cause problems for others using your classes.
由於Java編程語言不需要方法去捕獲或是指定未檢查異常(RuntimeException、Error、以及它們的子類)，程序員可能被吸引去寫僅僅拋出未檢查異常的代碼或是使他們自己的異常子類都繼承自RuntimeException。這兩種捷徑允許程序員寫代碼時不再被編譯器錯誤煩惱，或是被煩惱去指定或拋出任意異常。儘管這樣可能看起來對程序員很方便，但是它迴避了捕獲或指定需要的意圖，其他人在使用你的類時可能會造成問題。
Why did the designers decide to force a method to specify all uncaught checked exceptions that can be thrown within its scope? Any Exception that can be thrown by a method is part of the method’s public programming interface. Those who call a method must know about the exceptions that a method can throw so that they can decide what to do about them. These exceptions are as much a part of that method’s programming interface as its parameters and return value.
爲什麼設計者決定要強制一個方法去指定在它範圍內可能被拋出的所有未捕獲的受檢查異常？被方法拋出的任意Exception是方法的公開編程接口的一部分。調用方法的用戶必須要知道方法可能拋出的異常，因此他們可以決定對它們做什麼。這些異常是方法的編程接口，就像方法的參數返回值一樣。
The next question might be: “If it’s so good to document a method’s API, including the exceptions it can throw, why not specify runtime exceptions too?” Runtime exceptions represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way. Such problems include arithmetic exceptions, such as dividing by zero; pointer exceptions, such as trying to access an object through a null reference; and indexing exceptions, such as attempting to access an array element through an index that is too large or too small.
下一個問題可能是：如果記錄方法的API且包含它能拋出的異常是很好的，爲什麼不指定運行時異常。運行時異常表示問題是編程問題的一種結果，因此使用API的客戶端代碼不能合理地被期望從這些問題中恢復或是以任意方式處理它們。這樣的問題包含算術異常，比如除以0；指針異常，比如試着通過null引用訪問一個對象；索引異常，比如試着通過一個太大或是太小的索引值來訪問數組元素。
Runtime exceptions can occur anywhere in a program, and in a typical one they can be very numerous. Having to add runtime exceptions in every method declaration would reduce a program’s clarity. Thus, the compiler does not require that you catch or specify runtime exceptions (although you can).
運行時異常可能出現在程序的任何地方，比較典型的是他們可能是不計其數的。在每個方法聲明中添加運行時異常將會減少程序的清晰。因此編譯器不需要你捕獲或是指定運行時異常(儘管你可以這樣做)
One case where it is common practice to throw a RuntimeException is when the user calls a method incorrectly. For example, a method can check if one of its arguments is incorrectly null. If an argument is null, the method might throw a NullPointerException, which is an unchecked exception.
一種情況是當用戶不正確的調用方法而拋出運行時異常一種常見的實踐。舉個例子，一個方法可能檢查它的參數是否是不正確的null。如果一個參數是null，這個方法可能拋出一個NullPointerException，這是一個未檢查異常。
Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don’t want to be bothered with specifying the exceptions your methods can throw.
一般來講，不要拋出運行時異常或是創建運行時異常的子類，僅僅是因爲你不想爲指定你的方法能拋出異常而煩惱。
Here’s the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.
這裏有一個底線準則：如果一個客戶端能夠合理的被期望從異常中恢復，使它成爲一個受檢查異常。如果一個客戶端不能做任何事情去從異常中恢復，使它成爲一個未檢查異常。