Java Theory and Practice: an argument about anomalies

Most of the recommendations for using exceptions in the Java language suggest that check-type exceptions should be used preferentially in any case where the exception is believed to be captured. Language design (the compiler forces you to list all check-type exceptions that may be thrown in the method signature), as well as early writings on styles and usages, support this recommendation. Recently, several prominent authors have come to believe that unchecked anomalies have a more important place in the design of good Java classes than previously thought. In this article, Brian Goetz examines the pros and cons of using a non-checked type exception.

Like C + +, the Java language also provides exceptions for throwing and capturing. However, unlike C + +, the Java language supports both check-and-check-type exceptions. Java classes must declare any check-type exceptions that they throw in the method signature and, for any method, if the method it calls throws a check-type exception with the form E, it must either catch e or also declare it to throw an E (or a parent of e). In this way, the language forces us to document all the expected ways in which we can exit a method.

For exceptions caused by programming errors, or an exception that cannot be expected to be caught by the program (dereference a null pointer, array out of bounds, except 0, and so on), some exceptions are named unchecked exceptions (that is, those inherited from RuntimeException) and And you do not need to make a declaration.

The traditional view

The following excerpt from Sun's "The Java Tutorial" summarizes the traditional idea of declaring an exception to be checked or unchecked (see Resources for more information):

Because the Java language does not require methods to capture or specify Run-time exceptions, it is appealing to programmers to write code that throws only Run-time exceptions or that all their exception subclasses inherit from RuntimeException. These programming shortcuts allow programmers to write Java code without interfering with all the critical errors from the compiler, without having to specify or catch any exceptions. While this may seem convenient for programmers, it avoids Java capture or the intent to specify requirements, and can cause problems for programmers who use the classes you provide.

A check-type exception represents useful information about an operation that is legitimately specified, the caller may have no control over the operation, and the caller needs to be notified about-for example, the file system is full, or the connection is closed remotely, or the action is not allowed by the access permission.

If you throw a runtimeexception just because you don't want to specify an exception, or if you create a subclass of RuntimeException, what do you have in return? You just get the ability to throw an exception without you specifying to do so. In other words, this is a way to avoid the exceptions that a document method can throw. At what point is this beneficial? In other words, when is it useful to avoid the act of stating a method? The answer is "almost never." ”

In other words, Sun tells us that check-type abnormalities should be guidelines. The tutorial continues in a variety of ways, usually by throwing exceptions instead of runtimeexception--unless you are the JVM.

In effective java:programming Language Guide (see Resources), Josh Bloch provides the following knowledge points about check-and-check-type exceptions, as recommended in the "the Java Tutorial" Consistent (but not exactly consistent):

39th: Use exceptions for exception conditions only. That is, do not use exceptions for control flows, such as capturing nosuchelementexception at the time of the call to Iterator.next (), not the first time the Iterator.hasnext () is checked.

40th: Use a check-type exception for recoverable conditions, and use a Run-time exception for programming errors. Here, Bloch responds to the traditional Sun view that run-time exceptions should be used only to indicate programming errors, such as violating preconditions.

41st: Avoid unnecessary use of check-type exceptions. In other words, do not use a check-type exception for situations where the caller is unlikely to recover from it, or if the only predictable response is that the program exits.

43rd: Throw the exception that fits the abstraction. In other words, an exception thrown by a method should be defined at an abstract level that is consistent with what the method does, and not necessarily in accordance with the underlying implementation details of the method. For example, a method that loads a resource from a file, database, or JNDI should throw some kind of resourcenotfound exception (usually using an exception chain to hold the implied cause) instead of the lower IOException, SQLException, or N Amingexception.

Re-examining the orthodox view of non-censorship anomalies

Recently, several respected experts, including Bruce Eckel and Rod Johnson, have publicly stated that although they initially fully agreed with the orthodox view of censorship anomalies, they have decided that the idea of exclusive use of check-type anomalies is not as good as it initially appears, and for many large projects, Check-type exceptions have become an important source of problem. Eckel put forward a more extreme view, suggesting that all anomalies should be unchecked; Johnson's view should be conservative, but it still implies that traditional preference-checking abnormalities are excessive. (It is worth mentioning that the designer of C # chose to ignore the check-type exception in the language design so that all exceptions are not checked, so they are almost certainly rich in Java technology experience.) But then they did leave room for the implementation of the check-type exception. ）