Shulou(Shulou.com)06/02 Report--

How to analyze the difference between the two anomalies in Java language? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

A brief Analysis of the difference between two kinds of exceptions in Java language

Java provides two main types of exceptions: runtime exception and checked exception. All checked exception is derived from the java.lang.Exception class, while runtime exception is derived from the java.lang.RuntimeException or java.lang.Error class.

Their differences are shown in two aspects: mechanism and logic.

I. mechanically

Their differences in mechanism are shown in two points: 1. How to define the method; 2. How to handle the exception thrown. Take a look at the definition of CheckedException below:

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 ("... went wrong")

}

Public void method2 (String arg)

{

If (arg = = null)

{

Throw new NullPointerException ("the parameter arg of method2 is null!")

}

}

Public void method3 () throws CheckedException

{

Method1 ()

}

}

You may have noticed that both methods method1 () and method2 () throw exception, but only method1 () makes the declaration. In addition, method3 () itself does not throw exception, but it declares that it will throw CheckedException. Before we explain 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 put the call in the try/catch block because it throws a Checked exception.

By contrast, when you call method2 (), you don't need to put it in the try/catch block, because the exception it throws is not checked exception, but runtime exception. A method that throws a runtime exception does not have to declare that it throws an exception when defined.

Now, let's look at method3 () again. It calls method1 () but does not put the call in the try/catch block. It avoids doing so by declaring that it will throw the exception that method1 () will throw. Instead of capturing the exception, it passes it on. In fact, the main () method can do the same, by declaring that it throws Checked exception to avoid using try/catch blocks (which we object to, of course).

A brief summary:

* Runtime exceptions:

No declaration is required when defining a method. A runtime exception will be thrown.

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 class.

* Checked exceptions:

When defining a method, you must declare all checked exception that may be thrown

When you call this method, you must capture its checked exception, or you will have to pass its exception

Checked exception is derived from the java.lang.Exception class.

II. Logically

Logically speaking, checked exceptions and runtime exception are used for different purposes. Checked exception is used to indicate an exception that the 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 exception. Take, for example, the constructor of the java.net.URL class, where each builder throws a 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 uses this URL to download a web page. If the URL entered by the user is incorrect, the builder throws an exception. Since the exception is checked exception, your program can capture it and handle it correctly: for example, prompt the user to re-enter.

Take a look at the following example:

Public void method ()

{

Int [] numbers = {1,2,3}

Int sum = numbers [0] numbers [3]

}

You will encounter ArrayIndexOutOfBoundsException when running the method method () (because the members of the array numbers are from 0 to 2). The caller cannot handle / correct this exception. This method method (), like 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. However, program errors usually cannot be dealt with in the process of running, and the program code must be corrected.

All in all, when a checked exception is thrown while the program is running, only callers who can properly handle the exception should use try/catch to catch it. For runtime exception, it should not be captured in the program. If you want to capture it, you run the risk that the bug of the program code is hidden in the runtime and cannot be detected. Because in the process of program testing, the call stack path (StackTrace) printed by the system often makes you find and modify errors in the code more quickly. Some programmers suggest capturing runtime exception and recording it in log, which I object to. The downside of this is that you have to browse the log to find the problem, while the test system used to test the program (such as Unit Test) cannot directly capture the problem and report it.

After reading the above, have you mastered how to analyze the difference between the two anomalies in Java? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.