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

JAVA exception handling improper use of how to do, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

★ empty catch statement block

There are few people who make this kind of mistake, and it usually happens to people who have just learned Java or just started work.

The so-called "empty catch statement block" means that there is no handling of the exception (such as recording the error log) in the catch statement block, resulting in the exception information being discarded / ignored. Once the program can not run correctly, because no log information can be found, we have to look at the code from the beginning and rely on the naked eye to find bug.

★ does not use finally

Many people do not use catch statements after finally statements. Because the request and release of resources may be involved in the try statement. If an exception is thrown after the resource is requested and before the resource is released, a resource leak occurs.

★ general catch statement block

To save trouble, some people just package a block of try statements in the outermost code of their module, and then catch (Exception). No matter what exception is caught, do a unified log. This approach is slightly better than "empty catch statement blocks", but because specific exceptions cannot be specifically handled, some recoverable exceptions (mentioned below) lose the opportunity to recover. It may also lead to the problem of resource leakage mentioned above.

★ uses function return values for error handling

Some people do not use the exception mechanism of Java, but use the function return value to indicate success / failure (for example, return true for success, false for failure), which is simply "begging with a golden bowl". Personally, people who transfer from C to Java are more likely to have this problem. This practice will lead to the following problems:

1. The return value is generally expressed as an integer value or a Boolean value, and the message is too crude.

two。 Once the caller ignores the error return code, it will cause a problem similar to the "empty catch statement block".

two。 Multiple calls to the same function require repeated judgments on the return value, resulting in code redundancy.

★ doesn't know the difference between "Checked Exception" and "Runtime Exception".

This phenomenon is quite common, and I have found that many people with more than 2 years working experience in Java have not fully understood the difference between the two. It seems that this question needs to be explained in detail.

In the beginning, the designers of Java deliberately distinguished these two kinds of anomalies, which had a profound meaning. Where "Checked Exception" is used to indicate recoverable exceptions (that is, exceptions that you must check), and "Runtime Exception" refers to unrecoverable exceptions (that is, runtime exceptions, mainly program bug and fatal errors, which you [do not need] to check). However, this practice has caused a lot of controversy (including many Java bulls), and since this post is mainly aimed at novices, we will focus on this controversial topic later.

In order to make it easier to understand, let me give you an example. Suppose you want to write a Download function that returns the content text of the corresponding web page according to the passed URL (String parameter). There are two situations you need to deal with at this time:

1. If the URL parameter passed in is null, this means that the caller of the function is out of bug, and the bug of the program itself is difficult to recover at run time. At this point the Download function must throw a Runtime Exception. And the caller of the Download function [should not] try to handle the exception, but must expose it [as soon as possible] (such as letting JVM stop running itself).

two。 If the URL parameter passed in is not null, but the string it contains is not in a valid URL format (possibly due to a user input error). At this point the Download function must throw a Checked Exception. And the caller of the Download function must catch the exception and handle it accordingly (such as prompting the user to re-enter URL).

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.