(I) Exception hierarchy of Java
To understand the difference between checked Exception and unchecked Exception in Java, let’s first look at the exception hierarchy of Java.
This is a simplified Java exception hierarchy diagram. It should be noted that all classes are inherited from Throwable, and the next layer is divided into two structures, Error and Exception. The Error class level describes internal errors and resource exhaustion errors in the Java runtime system. In addition to simply reporting this error to the user and trying to prevent the program from being safely terminated, there are generally other solutions.
(II) The difference between unchecked exception and checked exception
After understanding the above, let’s take a look at what is checked exception and what is unchecked exception. In fact, the Java language specification defines these two very simple. Exceptions derived from Error or RuntimeException are called unchecked exceptions, and all other exceptions become checked exceptions . Although this definition is very simple, RuntimeException is a very confusing concept. It seems that all our exceptions are in the process of running the program. My explanation of Ru ntimeException in Effective Java is not so satisfactory.
Use checked exceptions for recoverable conditions and runtime exceptions for programming errors (Item 58 in 2nd edition)
However, from this sentence, we can simply extend it, that is, if a RuntimeException occurs, it must be a problem for the programmer himself. For example, array subscripts are out of bounds and accessing null pointer exceptions, etc. As long as you pay a little attention, these exceptions are exceptions that can be avoided in the encoding stage. If you still think these two concepts are difficult to distinguish, then the "most violent" method is to memorize the common RuntimeException, which can save a lot of time to judge.
(III) Why should we distinguish between unchecked exceptions and checked exceptions?
The reason is actually very simple. The compiler will check whether you provide an exception handling mechanism for all checked exceptions. For example, when we use Class.forName() to find the class object of a given string, if the exception handling is not provided for this method, the compilation will not be passed.
(IV) What exceptions should we declare?
As we said earlier, RuntimeException is an error that can be avoided during the programming process. So do we not need to throw these exceptions? In principle, this is true, but the Java specification does not limit this. It just seems that you throw an array out of bounds and there is no practical significance, and on the contrary, it will cause certain performance losses. So how should we design throw exceptions? We need to remember that the following two situations are necessary to declare throws exceptions:
Call a method of checked exception, such as IOException. As for the reason, we have discussed earlier, if all checked exceptions are thrown, it cannot be compiled. An error was found during the program running and an exception was thrown using the throw statement. For unchecked exceptions, there are only two main situations: either avoidable (Runtime Exception) or uncontrollable. These also require declaration of exceptions.
Here are examples to illustrate the awkward things mentioned in Note 2 above:
First, define a basic exception class GenericException, inherited from Exception.
package check_unchecked_exceptions;public class GenericException extends Exception{ /** * */ private static final long serialVersionUID = 2778045265121433720L; public GenericException(){ } public GenericException(String msg){ super(msg); }} The following defines a test class VerifyException.
package check_unchecked_exceptions;public class VerifyException { public void first() throws GenericException { throw new GenericException("checked exception"); } public void second(String msg){ if(msg == null){ throw new NullPointerException("unchecked exception"); } } public void third() throws GenericException{ first(); } public static void main(String[] args) { VerifyException ve = new VerifyException(); try { ve.first(); } catch (GenericException e) { e.printStackTrace(); } ve.second(null); }}After running, get the following information on the console of eclipse:
check_unchecked_exceptions.GenericException: checked exception
at check_unchecked_exceptions.VerifyException.first(VerifyException.java:6)
at check_unchecked_exceptions.VerifyException.main(VerifyException.java:23)
Exception in thread "main" java.lang.NullPointerException: unchecked exception
at check_unchecked_exceptions.VerifyException.second(VerifyException.java:11)
at check_unchecked_exceptions.VerifyException.main(VerifyException.java:29)
In the above example, combined with the concepts of checked and unchecked, it can be seen that the parent class Exception is of checked type, but its subclass RuntimeException (subclass NullPointerException) is unchecked.
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.