Documentation

The Java™ Tutorials
Hide TOC
Unchecked Exceptions — The Controversy未经检查的异常—争论
Trail: Essential Java Classes
Lesson: Exceptions

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.由于Java编程语言不需要方法来捕获或指定未检查的异常(RuntimeExceptionError及其子类),程序员可能会试图编写只抛出未检查异常的代码,或者使其所有异常子类继承RuntimeExceptionBoth 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.尽管这对程序员来说似乎很方便,但它避开了catchspecify需求的意图,并且可能会给使用您的类的其他人带来问题。

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.方法可以引发的任何Exception都是该方法的公共编程接口的一部分。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.这些异常与其参数和return值一样,也是该方法编程接口的一部分。

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?"下一个问题可能是:“如果记录一个方法的API(包括它可以抛出的异常)非常好,为什么不指定运行时异常呢?”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.运行时异常表示编程问题导致的问题,因此,不能合理地期望API客户机代码从中恢复或以任何方式处理它们。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.抛出RuntimeException是常见做法的一种情况是当用户错误地调用方法时。For example, a method can check if one of its arguments is incorrectly null.例如,一个方法可以检查它的一个参数是否错误地为nullIf an argument is null, the method might throw a NullPointerException, which is an unchecked exception.如果参数为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.一般来说,不要抛出RuntimeException或创建RuntimeException的子类,因为您不想为指定方法可以抛出的异常而烦恼。

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.如果客户端无法从异常中恢复,请将其设置为未检查的异常。


Previous page: Creating Exception Classes
Next page: Advantages of Exceptions