Java provides two main types of exceptions: Runtime exception and checked exception. All checked exception are derived from the Java.lang.Exception class, and the runtime Exception is derived from the Java.lang.RuntimeException or Java.lang.Error class.
Their differences are manifested in two ways: both institutional and logical.
First, the mechanism
Their differences in mechanism are shown at two points: 1. How to define a method; 2. How to handle the thrown exception. Consider the following definition of checkedexception:
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 ("... Error ");
}
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 exception, but only method1 () is declared. In addition, METHOD3 () itself does not throw exception, but it declares that it will throw 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 call METHOD1 (), you must place the call in the Try/catch program block because it throws checked exception.
By contrast, when you call METHOD2 (), you don't need to put it in the Try/catch block because it throws exception not checked exception, but runtime exception. The method that throws runtime exception does not have to be declared when it is defined to throw exception.
Now, let's take a look at method3 (). It calls Method1 () and does not place the call in the Try/catch program block. It is by declaring that it will throw method1 () will throw the exception to avoid doing so. It does not capture this exception, but passes it on. In fact, the main () method can do the same, by declaring that it throws checked exception to avoid the use of the Try/catch block (of course, we oppose this practice).
Summary:
* Runtime Exceptions:
No declaration is required when defining a method to throw runtime exception;
You do not need to capture this runtime exception when calling this method;
Runtime exception is derived from the Java.lang.RuntimeException or Java.lang.Error classes.
* Checked Exceptions:
When defining a method, you must declare all checked exception that may be thrown;
When calling this method, it must catch its checked exception, or it will have to pass its exception;
Checked exception is 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 condition that a caller can handle directly. Runtime exception is used to indicate a program error that cannot be handled or recovered by the caller itself.
Checked exception forces you to capture it and deal with this abnormal situation. Take the Java.net.URL Class Builder (constructor) as an example, and 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 goes through the URLDownload a webpage. 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, prompting the user to re-enter it.
Let's look at the following example:
public void Method ()
{
int [] numbers = {1, 2, 3};
int sum = numbers[0] numbers[3];
}
You encounter arrayindexoutofboundsexception when you run the method () (because the members of the array numbers are from 0 to 2). For this exception, the caller cannot process/correct. This method () is the same as the METHOD2 () above, which is the case of runtime exception. As I mentioned above, runtime exception is used to indicate a program error that cannot be handled/resumed by the caller itself. A program error is usually not handled during the run, and the program code must be corrected.
All in all, when a checked exception is thrown when a program is running, only the caller who can handle the exception appropriately should use Try/catch to capture it. For runtime exception, it should not be captured in the program. If you want to capture it, you take the risk that an error (bug) in the code of the program is obscured and cannot be detected in the run. Because during program testing, the system prints a call stack path (StackTrace) that often allows you to quickly find and modify errors in your code. Some programmers recommend capturing the runtime exception and logging it in log, which I oppose. The downside to this is that you have to browse through the log to find the problem, and the test system used to test the program (such as unit test) cannot directly capture the issue and report it.
Capturing runtime exception in your program also brings more problems: Which runtime exception do you want to capture? When is it captured? runtime exception no need to declare, how do you know if there is a runtime Exception to capture? Do you want to see the Try/catch program block used every time you call a method in your program?
Please respect others ' work success, reprint please indicate reprint place. Thank you! |
