Differences between Checked Exception and Runtime Exception

 

　　Java has an important feature: Exception, that is, allow the program to produce exceptions. When learning Java, we only know how to write exceptions, but we may not really understand the differences between different types of exceptions.

First, you should know that Java provides two Exception modes, one is the Exception (Runtime Exception) generated during execution ), the other is the controlled Exception (Checked Exception ).

All Checked exceptions are from java. lang. exception, while Runtime Exception inherits java. lang. runtimeException or java. lang. error (actually java. lang. the last layer of RuntimeException is java. lang. exception ).

When writing a program, we are likely to be troubled by choosing a form of Exception. Should I choose Runtime Exception or Checked Exception?

In fact, in terms of operation, we can understand the differences between them through how the Class Method generates an Exception and how a program processes the Exception generated.
First, create an Exception.

Public class CException extends Exception
{
Public CException (){}
Public CException (String message)
{
Super (message );
}
}

Then we write a Class that may produce CException.

Public class testException
{
Public void method1 () throws CException
{
Throw new CException ("Test Exception ");
}

Public void method2 (String msg)
{
If (msg = null)
{
Throw new NullPointerException ("Message is null ");
}
}

Public void method3 () throws CException
{
Method1 ();
}

// The following content is omitted
//...
}

In the three methods, we can see that both method1 and method2 generate an Exception in the code, but there is no Exception in the code of method3 (in braces, however, in the definition of method3, it implies that this method may generate CException.

CallThe method1 () program must include method1 () in try and catch, for example:

Public class runtest
{
//....
Public static void main (String argv [])
{
TestException te = new testException ();
Try
{
Te. method1 ();
}
Catch (CException ce)
{
//....
}
}
//...
}

Although it is included in try and catch, it does not mean that the program code will certainly receive CException, but it is intended to remind the caller of the possibility of unexpected execution of this method, the user must be able to handle this accident accordingly.

When you call method2 (), you do not need to use try and catch to wrap the program code, because in the definition of method2, there is no throws Exception, such:

Public class runtest
{
//....
Public static void main (String argv [])
{

TestException te = new testException ();

// No Exception is generated
Te. method2 ("Hello ");

// Exception
Te. method2 (null );
}
//...
}

NullPointerException is generated when the program is executed. This Exception is called runtime exception or unchecked exception. The method that generates Runtime Exception (method2 in this example) you do not need to define the Exception that will be generated when declaring a method.

InIn method3 () of testException, we see another situation, that is, method1 () is called in method3, but the method1 packet is not included in try and catch. On the contrary, in the definition of method3 (), it defines CException. In fact, if method3 receives a CException, it will not process this CException, but will discard it. Of course, because the definition of method3 contains throws CException, the program code for calling method3 also needs to have try catch.

Therefore, from the perspective of the program's operating mechanism, the Runtime Exception is different from the Checked Exception. However, logically, the Runtime Exception and Checked Exception are used for different purposes.

In general, Checked Exception indicates that the Exception must be processed. That is to say, the program designer should already know that it may receive an Exception (because try to catch it ), therefore, the program designer should be able to handle different Checked exceptions.

However, a Runtime Exception usually implies a program error, which may cause the program designer to be unable to handle and cause the program to fail to execute.

Take a look at the following example:

String message [] = {"message1", "message2", "message3 "};
System. out. println (message [3]);

This program code is no problem during Compile, but the Exception of ArrayIndexOutOfBoundException occurs during execution. In this case, we cannot make meaningful actions against this Runtime Exception, this is like calling method2 in testException but triggering NullPointerException. In this case, we must modify the program code to avoid this problem.

Therefore, in fact, we should also have to capture all the Checked exceptions. At the same time, it is best to handle these Checked exceptions so that the program can face different situations.

However,Runtime Exception. Some people suggest catch it and direct it to other places so that the program can continue to run. This is not a bad practice, but it will make us think that our program code is correct in some test tools, because we have dropped the Runtime Exception ", but it is not! For example, many people use a large try catch packet after the program entry point, such:

Public class runtest1
{
Public static void main (String argv [])
{
Try
{
//...
}
Catch (Exception e)
{
}
}
}

In this case, we may not know the Exception or the row from which the Exception is generated. Therefore, we can try to catch it separately in the face of different Checked exceptions. In the test phase, if we encounter a Runtime Exception, we can let it happen in this way, and then modify our program code to avoid the Runtime Exception. Otherwise, we should investigate every Exception carefully until we can make sure it does not have a Runtime Exception!

For Checked Exception and Runtime Exception, I think many people may have different ideas. In any case, the program must be able to execute these exceptions before they can be generated. Therefore, we can regard these exceptions as bugs, Checked exceptions, or Runtime exceptions ), but the premise is that we need to handle these exceptions. If we do not handle these exceptions, the problem or situation will remain there forever.