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

This article focuses on "Why not use try-catch-finally to handle Java exceptions". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let the editor take you to learn "Why not use try-catch-finally to handle Java exceptions"!

I. Preface

Before making a formal analysis, let's take a look at the execution sequence of a wave of finally.

1. Finally is not a necessary condition

In other words, there can be only try-catch or only try-finally in try-catch-finally.

2. Suppose it is based on try-catch-finally:

First: there is no exception in the code.

Execution order: try execution is complete-> catch does not execute-> finally execution

Second: the code has an exception and catch catches it.

Execution order: try execution part-> jump catch capture processing-> finally execution

Third: code has exceptions and catch does not catch: there is no catch in this case

Execution order: try execution part-> finally execution

As you can see from the above execution order, the finally statement is bound to be executed in either case. Based on this understanding, let's analyze it now.

Second, the shortcomings of try-finally

Take a look at the case first. This case is from "Effective java". Now you want to close the resource:

Static String firstLineOfFile (String path) throws IOException {BufferedReader reader = new BufferedReader (new FileReader (path)); try {return reader.readLine ();} finally {reader.close ();}}

It's okay to turn off one resource, but if you add a second resource, the code will look like a mess.

Static void copy (String src, String desc) throws IOException {InputStream in = new FileInputStream (src); try {OutputStream out = new FileOutputStream (desc); byte [] bytes = new byte [1024]; int n Try {while ((n = in.read (bytes))! =-1) {out.write (bytes, 0, n);}} finally {out.close ();}} finally {in.close ();}}

If you need to close not only a variety of resources, but also a large number of resources. That code is too big. Now let's sum up the shortcomings of this approach:

1. The closed resources are complicated and the code is complex.

two。 For the first case, if there is an exception on the device, calling readLine throws an exception, and the close method also throws an exception, in which case the close exception completely erases the readLine exception. There is also no record of readLine exceptions in the exception stack trace.

Now let's test one side:

Based on the above reasons, try-with-resources appeared.

III. Advantages of try-with-resources

Try-with-resources was introduced in jdk1.7 and can solve the above problems perfectly. To use this constructed resource, you must first implement the AutoCloseable interface, which contains a single close method that returns void. Many classes and interfaces in the Java class library and third-party class libraries now implement or extend the AutoCloseable interface, so we don't have to implement it now.

Now that try-with-resources can solve the above problems, let's take a look at how to solve them:

1. Solving the problem of code complexity

Static void copy (String src, String desc) throws IOException {try (InputStream in = new FileInputStream (src); OutputStream out = new FileOutputStream (desc)) {byte [] bytes = new byte [1024]; int n; while ((n = in.read (bytes))! =-1) {out.write (bytes, 0, n) }}}

You can see that in this way, the code is simpler, there is an error, and you can locate it quickly.

2. Exception erase problem solving

Static String firstLineOfFil (String path) throws IOException {try (BufferedReader reader = new BufferedReader (new FileReader (path) {return reader.readLine ();}}

If both the readLine and invisible close methods throw exceptions, the exceptions thrown by the close method will be disabled, which can not be seen in the try-finally processing mechanism, and cannot be printed in the stack trace, but try-with-resources will all be printed in the stack trace, indicating that they are forbidden exceptions and can be accessed by writing to call the getSuppressed method. Now let's test it again.

OK, almost all of the above has been analyzed, but this book also gives a better example:

Static String firstLineOfFile (String path, String defaultVal) {try (BufferedReader reader = new BufferedReader (new FileReader (path) {return reader.readLine ();} catch (IOException e) {return defaultVal;}}

This firstLineOfFile method does not throw an exception, but returns a default value if it cannot open the file or read from it.

At this point, I believe you have a deeper understanding of "Why not use try-catch-finally to handle Java exceptions". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.