[Android_exception] Checked and Runtime Exception differences

A very important feature in Java is the exception, which means that the program is allowed to produce exceptions. While learning Java, we only know the exception, but may not really understand the different kinds of exception differences.

first of all, you should know that Java provides two Exception modes, one is the Exception (Runtime Exception) generated when executing, and the other is a controlled Exception (Checked Exception).

all checked Exception inherit from Java.lang.Exception, and runtime Exception inherits Java.lang.RuntimeException or Java.lang.Error (actually the upper layer of java.lang.RuntimeException is also java.lang.Exception).

when we write a program, we are likely to be troubled by the choice of some form of Exception, should I choose Runtime Exception or checked Exception?

in fact, in operation, we can understand the difference by how the class method produces a exception and how a program handles the resulting exception.
first, let's build a 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 ();
}

//omitted below
// ...
}

In these three method, we see METHOD1 and METHOD2 in the code will produce exception, but method3 code (in curly braces), does not produce exception, but in the definition of method3, implies that this method may produce cexception.

a program that calls METHOD1 () must include METHOD1 () in a try and catch, such as:

Public class Runtest
{
// ....
Public static void Main (String argv[])
{
testexception te = new TestException ();
Try
{
te.method1 ();
}
catch (cexception CE)
{
// ....
}
}
// ...
}

Although included in the try and catch, does not mean that this code will receive cexception, but it is intended to remind the caller, the execution of this method may be caused by the accident, and the user must be able to respond to this accident corresponding processing.

when a consumer calls METHOD2 (), it is not necessary to package the code with a try and catch because the definition of METHOD2 does not throws any exception, such as:

Public class Runtest
{
// ....
Public static void Main (String argv[])
{

testexception te = new TestException ();

//does not produce Exception
te.method2 ("Hello");

//will produce Exception
te.method2 (null);
}
// ...
}

program in the implementation of the time, it is not likely to really produce nullpointerexception, this exception called runtime exception also known as unchecked exception, resulting runtime Exception's method (Method2 in this example) does not need to define which Exception it will produce when declaring the method.

In TestException's method3 (), we see another situation where method3 calls Method1 (), but does not wrap method1 between try and catch. Instead, in the definition of method3 (), it defines the cexception, which is actually if METHOD3 receives the CException, it will not process the cexception and throw it out. Of course, because the definition of method3 has throws CException, the code that calls METHOD3 also needs a try catch.

therefore, from the operational mechanism of the program, runtime Exception and checked Exception not the same, but logically, runtime Exception and checked Exception in the purpose of use is not the same.

in general, Checked Exception indicates that the Exception must be handled, meaning that the programmer should already know that a certain Exception may be received (as a try catch), So the programmer should be able to deal with these different checked Exception differently.

runtime Exception often implies procedural errors, which can cause the program designer to be unable to process and cause the program to continue executing.

Take a look at the following example:

String message[] = {"Message1", "Message2", "Message3"};
System.out.println (message[3]);

This code is not a problem when compile, but in the implementation of the arrayindexoutofboundexception exception, in this situation, we also can not be targeted at the runtime Exception to make meaningful actions, It's like we're calling the Method2 in TestException, but it's nullpointerexception like that, in which case we have to modify the code to avoid this problem.

so, in fact, we should also have to crawl all the checked Exception, at the same time it is best to make these checked Exception occur when the corresponding processing, so that the program can face different situations.

for runtime Exception, however, it's not bad that some people suggest that it be caught and then directed elsewhere to allow the program to continue, but it will allow us to think of our code under some test tools, because we will run the runtime Exception "Processing" dropped, but the truth is not! For example, many people's habit is to use a large try catch after the entry point of the program, such as:

Public class Runtest1
{
Public static void Main (String argv[])
{
Try
{
//...
}
catch (Exception e)
{
}
}
}

in this case, we will probably not know what happened exception or from which line, so in the face of different checked exception, we can go to try catch it separately. And in the test phase, if you encounter runtime Exception, we can let it happen, and then to modify our program code, let it avoid runtime Exception, otherwise, we should carefully investigate every Exception, Until we can be sure it won't have runtime Exception!

for checked Exception and runtime Exception, I think there are a lot of people will have different views, in any case, the process should be able to execute, these Exception have the opportunity to produce. So we can think of these Exception as bugs, or as different situations (Checked Exception), or as tools to help us debug (Runtime Exception), but only if we need to deal with these Exception, If it is not dealt with, then the problem or condition will remain there forever.