JAVA异常翻译（五）

原文链接
原文：
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.

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.

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.

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.

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.

译文：

非受检异常-争议

因为Java编程语言没有要求方法捕获或者制定非受检异常（运行时异常，错误，以及他们的子类），程序员可能会去写只抛出非受检异常的代码，或者写代码让这些异常的所有子类继承运行时异常。这些捷径让程序员写代码时不用担心被编译器错误，也不用担心指定或者捕获异常。尽管这种方式对程序员看起来好像很方便，但他回避了捕获或者指定要求的目的，而且会导致其他人使用你写的类时碰到问题。
为什么设计者决定强制让一个方法在他的范围里抛出所有未被捕捉的受检异常？任何能被一个方法抛出的异常都是这个方法公共编程接口的一部分。那些调用方法的人必须了解这个方法可能会抛出的异常，这样他们能决定对如何处理它们。这些异常和方法的参数以及返回值一样，也是编程接口的一部分。
下一个问题可能是：“如果记录方法的API是好的，包括他可能会抛出的异常，为什么不定义运行时异常呢？”运行时异常呈现了程序运行结果的问题，正因如此，API的客户端代码不能合理的预计还原或者用任何方式解决他们。一些问题包括了算术异常，比如除以零；指针异常，比如尝试用空引号访问一个对象；以及索引异常，比如试着通过一个太大或者太小的索引去访问一个数组元素。
运行时异常会在一个程序的任何地方出现，在一个典型的例子里它可能会有很多。在每个方法声明里添加运行时异常会减少一个程序的清晰度。因此，编译器不要求要你抛出或者定义运行时异常（尽管你可以）。
当用户没有正确的调用一个方法时，会抛出一个运行时异常。举个例子，一个方法会检查他的一个参数是否是不正确的空值。如果一个参数是空值，方法可能会抛出空指针异常，是一个非受检异常。
一般来说，不要轻易地抛出一个运行时异常或者新建一个运行时异常的子类，因为你不想被来自你的方法定义的会抛出的异常打扰。
这是底限原则：如果一个客户端会合理的预料从一个异常还原，让他成为一个受检异常。如果一个客户端不能做任何事来从异常还原，让他成为一个非受检异常。