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.
这里有一个底线准则：如果一个客户端能够合理的被期望从异常中恢复，使它成为一个受检查异常。如果一个客户端不能做任何事情去从异常中恢复，使它成为一个未检查异常。