Do you think you are a Java expert? Are you sure you have fully mastered the Java exception handling mechanism? In the following code, can you quickly find the six problems for exception handling?
1 outputstreamwriter out =...
2 Java. SQL. Connection conn =...
3 try {// retry
4 Statement stat = conn. createstatement ();
5 resultset rs = stat.exe cutequery (
6 "select uid, name from user ");
7 while (Rs. Next ())
8 {
9 out. println ("ID:" + Rs. getstring ("uid") // response
10 ", name:" + Rs. getstring ("name "));
11}
12 conn. Close (); // (3)
13 out. Close ();
14}
15 catch (exception ex) // (2)
16 {
17 ex. printstacktrace (); // (1), (4)
18}
|
As a Java programmer, you should be able to identify at least two problems. However, if you cannot find all six questions, read this article. This article does not discuss general principles of Java Exception Handling, because these principles are well known to most people. What we need to do is to analyze common bad habits that can be called "anti-pattern" (Anti-pattern) against excellent coding specifications and help readers familiarize themselves with these typical negative examples, in this way, you can perceive and avoid these problems keenly in your actual work. Counterexample: discard exception Code: Lines 15-18. This code captures exceptions without any processing. It can be regarded as a killer in Java programming. In terms of the frequency and severity of the problem, it may be comparable to that of the C/C ++ program ?? Do not check whether the buffer zone is full. If you see this discard (rather than throw) exception, you can be 99% sure that the code is faulty (in rare cases, this code has a reason, but it is best to add a complete comment to avoid misunderstanding ). The error in this Code is that exceptions (almost) always mean something is wrong, or at least something unusual happens, we should not remain silent or indifferent to the distress signals sent by the program. Calling printstacktrace does not count as "Exception Handling ". Yes. Calling printstacktrace is helpful for debugging programs. However, after the program debugging stage ends, printstacktrace should no longer take the primary responsibility in the Exception Handling Module. Discard exceptions are common. Open the JDK threaddeath class document and you can see the following description: "In particular, although threaddeath is a 'normal situation ', the threaddeath class is a subclass of error rather than exception, because many applications capture all exceptions and discard them." This section indicates that, although threaddeath represents a common problem, many applications attempt to capture all exceptions and then do not handle them properly, therefore, JDK defines threaddeath as a subclass of error, because the error class represents a serious problem that general applications should not capture. It can be seen that the habit of dropping exceptions is so common that it has even affected Java's design. So how should we correct it? There are four main options: 1. handle exceptions. Actions should be taken to fix the exception, such as correcting the problem, reminding a person or performing other actions according to the specific situation. Again, calling printstacktrace does not count as "handled exceptions ". 2. Throw an exception again. After analyzing an exception, the code that handles the exception considers itself unable to handle it, and throwing an exception again is also an option. 3. Convert the exception to another exception. In most cases, this refers to converting a low-level exception to an application-level exception (which means exceptions that are more easily understood by users ). 4. Do not capture exceptions. Conclusion 1: as exceptions are captured, appropriate processing is required. Do not discard an exception and ignore it. Counterexample 2: do not specify a specific exception Code: 15 lines. In many cases, people will be attracted by such a "wonderful" idea: Catch all exceptions with a catch statement. The most common case is to use catch (exception ex) statements. But in fact, in most cases, this approach is not worth advocating. Why? To understand the cause, we must review the usage of the catch statement. The catch statement indicates that we expect an exception and want to handle it. The function of the exception class is to tell the Java compiler which exception we want to handle. Since most exceptions are derived directly or indirectly from Java. Lang. exception, catch (exception ex) is equivalent to saying that we want to handle almost all exceptions. Let's take a look at the previous code example. What exceptions do we really want to capture? The most obvious one is sqlexception, which is a common exception in JDBC operations. Another possible exception is ioexception because it needs to operate outputstreamwriter. Obviously, it is not appropriate to handle these two distinct exceptions in the same Catch Block. If two catch blocks are used to capture sqlexception and ioexception respectively, it is much better. That is to say, the catch statement should specify the exception type as much as possible, instead of the exception class with a wide scope. On the other hand, in addition to these two specific exceptions, many other exceptions may also occur. For example, what if executequery returns NULL for some reason? The answer is to let them continue to throw, that is, they do not need to be captured or processed. In fact, we cannot and should not capture all possible exceptions. Are there other opportunities for programs to capture exceptions ?? Until it is finally processed by JVM. |
