Java provides two main types of exceptions: Runtime exception and checked exception. All the checked exception are derived from the Java.lang.Exception class, and runtime Exception are derived from Java.lang.RuntimeException or Java.lang.Error classes.
Their differences are manifested in two aspects: the mechanism and the logic.
First, the mechanism
Their differences in mechanism are expressed at two points: 1. How to define a method; 2. How to handle thrown exceptions. Consider the following checkedexception definition:
public class Checkedexception extends Exception
{
Public checkedexception () {}
Public checkedexception (String message)
{
Super (message);
}
} |
And an example of using exception:
public class Exceptionalclass
{
public void Method1 ()
Throws Checkedexception
{
... throw new Checkedexception ("... Made a mistake ");
}
public void Method2 (String arg)
{
if (arg = = null)
{
throw new NullPointerException ("Method2 parameter arg is null!");
}
}
public void Method3 () throws Checkedexception
{
Method1 ();
}
} |
As you may have noticed, two methods method1 () and METHOD2 () will throw the exception, but only method1 () make a declaration. In addition, METHOD3 () itself does not throw exception, but it declares that it throws checkedexception. Before explaining to you, let's take a look at the main () method of this class:
public static void Main (string[] args)
{
exceptionalclass example = new Exceptionalclass ();
Try
{
Example.method1 ();
Example.method3 ();
}
catch (Checkedexception ex) {} example.method2 (null);
} |
In the main () method, if you want to invoke Method1 (), you must place the call in the Try/catch block because it throws checked exception.
In contrast, when you call METHOD2 (), you do not need to place it in the Try/catch block, because it throws exception not checked exception, but runtime exception. A method that throws runtime exception does not have to declare that it throws a exception when it is defined.
Now, let's take a look at method3 (). It calls Method1 () but does not place the call in the Try/catch program block. It is avoided by declaring that it throws the exception that Method1 () throws. It does not capture this exception, but it passes it down. In fact, the main () method can also do this by declaring that it throws checked exception to avoid using the Try/catch program block (which we are opposed to).
Summary：
* Runtime Exceptions:
When you define a method, you do not need a declaration to throw a runtime exception;
You do not need to capture this runtime exception when calling this method;
Runtime exception are derived from Java.lang.RuntimeException or Java.lang.Error classes.
* Checked Exceptions:
When you define a method, you must declare all checked exception that might be thrown;
When this method is invoked, it must be captured by its checked exception, or it will have to pass its exception;
Checked exception are derived from the Java.lang.Exception class.
second, logically
From a logical point of view, checked exceptions and runtime exception are used for different purposes. Checked exception is used to indicate an exception that a caller can handle directly. Runtime exception is used to indicate a program error that the caller itself cannot handle or recover.
Checked exception forces you to capture it and handle this anomaly. As an example of a Java.net.URL class builder (constructor), each of its builders throws malformedurlexception. Malformedurlexception is a kind of checked exception. Imagine that you have a simple program that prompts the user to enter a URL and then downloads a Web page through the URL. If the user enters a URL with an error, the builder throws a exception. Since this exception is checked exception, your program can capture it and handle it correctly: For example, prompt the user to re-enter.
Let's look at the following example:
public void Method ()
{
int [] numbers = {1, 2, 3};
int sum = Numbers[0] + numbers[3];
} |
ArrayIndexOutOfBoundsException (because the members of the array numbers are from 0 to 2) are encountered when you run method methods (). For this exception, the caller cannot handle/correct. This method (), like the Method2 () above, is the case of runtime exception. As I mentioned above, runtime exception is used to indicate a program error that the caller itself cannot handle/recover. While program errors are usually not handled during the run, you must correct the program code.
All in all, when a checked exception is thrown in the process of running a program, only a call that can properly handle this exception should be captured with Try/catch. For runtime exception, you should not capture it in your program. If you want to capture it, you risk that the bugs in the program code will be obscured and not detected in operation. Because during program testing, the system's printed call stack path (StackTrace) often allows you to quickly find and modify errors in your code. Some programmers suggest capturing runtime exception and recording it in log, which I object to. The downside is that you have to browse the log to find the problem, and the test system (such as unit test) that is used to test the program cannot directly capture the issue and report it.
Capturing runtime exception in your program can also cause more problems: which runtime exception to capture. When to capture. Runtime exception is not required to declare, how do you know if there is runtime exception to capture. Do you want to see the Try/catch program block used every time you call a method in your program?
