Java Theory and Practice: Balancing test, Part 2nd: Writing and Optimizing bug detectors

The 1th part of this short series describes how to test effectively, building the FindBugs plug-in to find a simple bug pattern (just call System.GC ()). Bug patterns identify problematic coding practices that are often located in the area where the bug is located. Of course, not all bug patterns are necessarily bugs, but that doesn't negate the huge impact of bug pattern detectors. The main function of a valid bug pattern detector is to discover a higher percentage of suspicious code, making the pattern more useful. Creating a bug pattern Checker can improve use value; After you create a detector, you can run it on whatever code you need, both now and in the future, and you may be surprised by the problems you find. For example, the simple detector in part 1th shows a call to System.GC (), which, in JDK 1.4.2, is hidden in the JPEG image I/O library.

It is not difficult to write a detector to find calls to a particular static method, but most bug detectors contain considerable analysis and implementation. In this installment of the article, you will develop a detector for a smaller bug pattern called RuntimeException capture (currently included with this bug detector in the FindBugs release). ）

RuntimeException capture

One advantage of exception handling in the Java™ language is that exceptions are objects, the Try-catch mechanism understands the hierarchical structure of exception types, and provides practical flexibility in how the client handles error handling. For example, if a file cannot be found, the FileInputStream constructor throws a FileNotFoundException, which is a subclass of IOException. This traditional usage allows clients to process conditions for files that are not found, separated from other file-related conditions (if they prefer to capture filenotfoundexception separately). However, they can also handle all file-related error conditions using the capture IOException method.

On the other hand, the main flaw in exception handling is that it is easy to establish a method with three or four lines of business logic and 20 or 30 rows of exception handling when the exception is used correctly. Because the error recovery code is prone to errors in testing and difficult to perform, some code that specializes in exception handling is confusing and error prone. A typical example of this scenario, as shown in the list, is that a method with two lines of "true" code requires three separate capture blocks, each of which performs exactly the same operation--Logging the exception:

Listing 1. Multiple identical capture blocks

public　void　addInstance(String　className)　{
　　 try　{
　　　　 Class　clazz　=　Class.forName(className);
　　　　 objectSet.add(clazz.newInstance());
　　 }
　　 catch　(IllegalAccessException　e)　{
　　　　 logger.log("Exception　in　addInstance",　e);
　　 }
　　 catch　(InstantiationException　e)　{
　　　　 logger.log("Exception　in　addInstance",　e);
　　 }
　　 catch　(ClassNotFoundException　e)　{
　　　　 logger.log("Exception　in　addInstance",　e);
　　 }
}

See Listing 1, you might try to merge the three capture blocks into a separate capture block that captures Exception, because the capture recovery operations for each capture block are the same. At first glance, the strategy seems like a good approach-but there are errors in the copy of the code, so consolidating these replication paths should be an improvement. However, this "improvement" often brings unexpected results. Because RuntimeException extends Exception, merging three capture blocks into a single capturing block (shown in Listing 2), this changes semantics, and now unchecked exceptions are logged (not propagated). This bug pattern, where runtimeexception is easily captured by oversized capture blocks, is also known as runtimeexception capture.

Listing 2. RuntimeException catch bug pattern-do not perform this mode

public　void　addInstance(String　className)　{
　　 try　{
　　　　 Class　clazz　=　Class.forName(className);
　　　　 objectSet.add(clazz.newInstance());
　　 }
　　 catch　(Exception　e)　{
　　　　 logger.log("Exception　in　newInstance",　e);
　　 }
}