Check-type and unchecked-type exceptions

For exceptions caused by programming errors, or exceptions 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 Exception) and does not need to be declared.

Checked Exception and unchecked exception the difference between the method signature is required to declare whether exception calls the method needs to be captured exception The state of the JVM control program when exception arises

Sun's "The Java Tutorial" view because the Java language does not require methods to capture or specify Run-time exceptions, write code that throws only Run-time exceptions or makes all of their exception subclasses inherit from RuntimeException. is appealing to programmers. 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 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 this is beneficial. In other words, it is useful to avoid the act of stating a method at any time. 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 checked and unchecked exceptions that are consistent with the recommendations in the "The Java Tutorial" (but not exactly consistent): rule 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 Resourcenotfound exception (usually using an exception chain to hold the implied cause) when the resource cannot be found, rather than the lower IOException, SQLException, or Namingexception.

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. ）

whether using check-type exceptions

The decision about whether to use a check-type exception is complex, and obviously there is no obvious answer. Sun's advice is to use them for any situation, and the C # method (that is, Eckel and others agree) is not used for anything. Other people say, "There is a middle case." ”