Findbugs缺陷等级对照表

Findbugs缺陷等级对照表FindBugs Bug Descriptions This document lists the standard bug patterns reported by version 0.8.5. Summary 序等号 级 14 A Description Category Correctness Correctness EC: Call to equals with null argument 调用Equal方法的参数为空 EC: Call to equals comparing different 15 A interface types 调用Equal方法去比较不同的接口类型 EC: Call to equals comparing different 16 A types 调用Equal方法去比较不同的数据类型 ES: Comparison of String objects using == 17 A or != 使用== 或者 != 去比较字符串或对象 IJU: TestCase implements setUp but doesn't call super.setUp 29 B 测试实例实现了setUp但没有调用super.setUp 36 A NP: Null pointer dereference in method 方法中存在空指针 Correctness Correctness Correctness Correctness Correctness NP: Null pointer dereference in method on 37 A exception path 方法中存在某异常路径中的空指针 NP: Possible null pointer dereference in 38 A method 方法中存在可能在运行时出现的空指针异常 Correctness NP: Possible null pointer dereference in method on exception path 39 A Correctness 方法中存在可能在某些异常路径下出现的空指针异常 Nm: Class defines equal; should it be equals? 41 C 类中定义了equal方法，但是没有重写Correctness java.lang.Object中equal方法，这也有可能是有意这么做的 42 B 43 B Nm: Confusing method names 一些方法名只有大小写的区别，容易混绕 Nm: Confusing method name 方法名和其超类的类名相同 Correctness Correctness Nm: Class defines hashcode; should it be hashCode? 44 C 类中定义了hashCode方法，但是没有重写java.lang.Object中的hashCode方法，这也有可能是有意这么做的 Nm: Class defines tostring; should it be toString? 45 C 类中定义了tostring方法，但是没有重写java.lang.Object中的tostring方法，这也有可能是有意这么做的 46 A Nm: Very confusing method names 一些方法名只有大小写的区别，特别容易混绕 Correctness Correctness Correctness Correctness ODR: Method may fail to close database 47 A resource 方法可能没有关闭数据源 ODR: Method may fail to close database 48 A resource on exception 方法在异常时可能无法关闭数据源 49 A OS: Method may fail to close stream 方法可能没有关闭流 Correctness Correctness Correctness OS: Method may fail to close stream on 50 A exception 方法在异常时可能无法关闭流 RCN: Redundant comparision to null of 53 C previously checked value 预测值的几个比较的值中有null值 54 C 57 C RCN: Redundant comparison to null 几个比较的值中有null值 RV: Method ignores return value 方法忽略了返回值 Correctness Correctness Correctness SI: Static initializer for class creates instance before all static final fields 59 A assigned Correctness 类的静态初始化器实例化一个该类对象要在所有的常量属性定义之前 72 C UwF: Unwritten field 永远不会写到的字段，所有读取将返回默认值 Correctness 83 A 86 A MS: Field isn't final but should be 字段应该为常量的却不是常量 IS2: Inconsistent synchronization 类中字段访问不同步 Malicious code vulnerability Multithreaded correctness ML: Method synchronizes on an updated field 方法从一个可变字段对象的引用中同步。

这是不太Multithreaded 88 A 可能有用的，因为不同的线程可以在不同的对象上correctness 同步 Ru: Invokes run on a thread (did you mean to start it instead?) Multithreaded 92 C 当一个类继承Runnable接口时候，还去调用run方correctness 法，实际上只需要调用Start方法就可以启动新的线程， 93 C SC: Constructor invokes Thread.start 构造函数调用Thread.start Multithreaded correctness Dm: Method invokes dubious new String(String) constructor; just use the 102 C argument 方法中调用String的构造函数来新建一个字符串，直接使用其参数即可 Performance Dm: Method invokes dubious String.equals(""); use String.length == 0 103 A instead Performance 方法中调用了不确定的String.equals("")，使用String.length == 0来代替 Dm: Method invokes toString method on a String; just use the String 104 A Performance 方法中用一个字符串去调用方法toString，用String就可以了 Dm: Method invokes dubious new String constructor; just use "" 105 C Performance 方法中新建一个空字符串用new String。

直接用“”就可以了 FI: Empty finalizer should be deleted 106 C 空finalizer方法是没有用的，所以应该予Performance 以删除 114 C 115 C UPM: Private method is never called 这个私有方法从来没有被调用到 UrF: Unread field 读不到的字段，应该从类中删除 Performance Performance Performance 116 C UuF: Unused field 读不到的字段，应该从类中删除 Descriptions AM: Creates an empty jar file entry The code calls putNextEntry, immediately followed by a call to closeEntry. This results in an empty JarFile entry. The contents of the entry should be written to the JarFile between the calls to putNextEntry and closeEntry. AM: Creates an empty zip file entry The code calls putNextEntry, immediately followed by a call to closeEntry. This results in an empty ZipFile entry. The contents of the entry should be written to the ZipFile between the calls to putNextEntry and closeEntry. BIT: Incompatible bit masks This method compares an expression of the form (a & C) to D, which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo. BIT: Incompatible bit masks This method compares an expression of the form (a & 0) to 0, which will always compare equal. This may indicate a logic error or typo. BIT: Incompatible bit masks This method compares an expression of the form (a | C) to D. which will always compare unequal due to the specific values of constants C and D. This may indicate a logic error or typo. Typically, this bug occurs because the code wants to perform a membership test in a bit set, but uses the bitwise OR operator ("|") instead of bitwise AND ("&"). BOA: Class overrides a method implemented in super class Adapter wrongly This method overrides a method found in a parent class, where that class is an Adapter that implements a listener defined in the java.awt.event or javax.swing.event package. As a result, this method will not get called when the event occurs. BRSA: Method attempts to access a result set field with index 0 A call to getXXX or updateXXX methods of a result set was made where the field index is 0. As ResultSet fields start at index 1, this is always a mistake. CN: Class implements Cloneable but does not define or use clone method Class implements Cloneable but does not define or use the clone method. CN: clone method does not call super.clone This class defines a clone method that does not call super.clone, and is not final. If this class ("A") is extended by a subclass ("B"), and the subclass B calls super.clone, then it is likely that B's clone method will return an object of type A, which violates the standard contract for clone. If all clone methods call super.clone, then they are guaranteed to use Object.clone, which always returns an object of the correct type. Co: Covariant compareTo method defined This class defines a covariant version of compareTo. To correctly override the compareTo method in the Comparable interface, the parameter of compareTo must have type java.lang.Object. DE: Method might drop exception This method might drop an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method. DE: Method might ignore exception This method might ignore an exception. In general, exceptions should be handled or reported in some way, or they should be thrown out of the method. Dm: Method invokes System.exit(...) Invoking System.exit shuts down the entire Java virtual machine. This should only been done when it is appropriate. Such calls make it hard or impossible for your code to be invoked by other code. Consider throwing a RuntimeException instead. EC: Call to equals with null argument This method calls equals(Object), passing a null value as the argument. According to the contract of the equals method, this call should always return false. EC: Call to equals comparing different interface types This method calls equals(Object) on two references of unrelated interface types (neither is a subtype of the other). According to the contract of equals, objects of different classes should always compare as unequal. Note that it is possible that the program contains classes that implement both interfaces, so the comparison may be valid. However, it is worth inspecting closely. EC: Call to equals comparing different types This method calls equals(Object) on two references of different types. According to the contract of equals, objects of different classes should always compare as unequal; therefore, it is likely that the result of this comparision will always be false at runtime. ES: Comparison of String objects using == or != This code compares java.lang.String objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the String.intern method, the same string value may be represented by two different String objects. Consider using the equals(Object) method instead. Eq: Covariant equals method defined This class defines a covariant version of equals. To correctly override the equals method in java.lang.Object, the parameter of equals must have type java.lang.Object. Eq: Covariant equals method defined, Object.equals(Object) inherited This class defines a covariant version of the equals method, but calls the normal equals(Object) method defined in the base java.lang.Object class. The class should probably define a non-covariant version of equals. (I.e., a method with the signature boolean equals(java.lang.Object). FI: Explicit invocation of finalizer This method contains an explicit invocation of the finalize method on an object. Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea. FI: Finalizer does not call superclass finalizer This finalize method does not make a call to its superclass's finalize method. So, any finalizer actions defined for the superclass will not be performed. Add a call to super.finalize. FI: Finalizer nullifies superclass finalizer This empty finalize method explicitly negates the effect of any finalizer defined by its superclass. Any finalizer actions defined for the superclass will not be performed. Unless this is intended, delete this method. HE: Class defines equals but not hashCode This class overrides equals(Object), but does not override hashCode. Therefore, the class may violate the invariant that equal objects must have equal hashcodes. HE: Class defines equals and uses Object.hashCode This class overrides equals(Object), but does not override hashCode, and inherits the implementation of hashCode from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes. If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode method to throw UnsupportedOperationException. HE: Class defines hashCode but not equals This class defines a hashCode method but not an equals method. Therefore, the class may violate the invariant that equal objects must have equal hashcodes. HE: Class defines hashCode and uses Object.equals This class defines a hashCode method but inherits its equals method from java.lang.Object (which defines equality by comparing object references). Although this will probably satisfy the contract that equal objects must have equal hashcodes, it is probably not what was intended by overriding the hashCode method. (Overriding hashCode implies that the object's identity is based on criteria more complicated than simple reference equality.) HE: Class inherits equals and uses Object.hashCode This class inherits equals(Object) from an abstract superclass, and hashCode from from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by the VM). Therefore, the class is very likely to violate the invariant that equal objects must have equal hashcodes. If you don't want to define a hashCode method, and/or don't believe the object will ever be put into a HashMap/Hashtable, define the hashCode method to throw UnsupportedOperationException. IC: Initialization circularity A circularity was detected in the static initializers of the two classes referenced by the bug instance. Many kinds of unexpected behavior may arise from such circularity. IJU: TestCase implements setUp but doesn't call super.setUp Class is a JUnit TestCase and implements the setUp method. The setUp method should call super.setUp, but doesn't. IMSE: Dubious catching of IllegalMonitorStateException IllegalMonitorStateException is generally only thrown in case of a design flaw in your code (calling wait or notify on an object you do not hold a lock on). It: Iterator next method can't throw NoSuchElement exception This class implements the java.util.Iterator interface. However, its next method is not capable of throwing java.util.NoSuchElementException. The next method should be changed so it throws NoSuchElementException if is called when there are no more elements to return. MF: Class defines field that obscures a superclass field This class defines a field with the same name as a visible instance field in a superclass. This is confusing, and may indicate an error if methods update or access one of the fields when they wanted the other. MF: Method defines a variable that obscures a field This method defines a local variable with the same name as a field in this class or a superclass. This may cause the method to read an uninitialized value from the field, leave the field uninitialized, or both. MWN: Mismatched notify This method calls Object.notify or Object.notifyAll without obviously holding a lock on the object. Calling notify or notifyAll without a lock held will result in an IllegalMonitorStateException being thrown. MWN: Mismatched wait This method calls Object.wait without obviously holding a lock on the object. Calling wait without a lock held will result in an IllegalMonitorStateException being thrown. NP: Null pointer dereference in method A null pointer is dereferenced here. This will lead to a NullPointerException when the code is executed. NP: Null pointer dereference in method on exception path A pointer which is null on an exception path is dereferenced here. This will lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning. Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible. NP: Possible null pointer dereference in method A reference value dereferenced here might be null at runtime. This may lead to a NullPointerException when the code is executed. NP: Possible null pointer dereference in method on exception path A reference value which is null on some exception control path is dereferenced here. This may lead to a NullPointerException when the code is executed. Note that because FindBugs currently does not prune infeasible exception paths, this may be a false warning. Also note that FindBugs considers the default case of a switch statement to be an exception path, since the default case is often infeasible. NS: Questionable use of non-short-circuit logic This code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or ||). Non-short-circuit logic causes both sides of the expression to be evaluated even when the result can be inferred from knowing the left-hand side. This can be less efficient and can result in errors if the left-hand side guards cases when evaluating the right-hand side can generate an error. Nm: Class defines equal; should it be equals? This class defines a method equal(Object). This method does not override the equals(Object) method in java.lang.Object, which is probably what was intended. Nm: Confusing method names The referenced methods have names that differ only by capitalization. Nm: Confusing method name This method has the same name as the superclass of the class it is defined in. Nm: Class defines hashcode; should it be hashCode? This class defines a method called hashcode. This method does not override the hashCode method in java.lang.Object, which is probably what was intended. Nm: Class defines tostring; should it be toString? This class defines a method called tostring. This method does not override the toString method in java.lang.Object, which is probably what was intended. Nm: Very confusing method names The referenced methods have names that differ only by capitalization. ODR: Method may fail to close database resource The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the object on all paths out of the method. Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database. ODR: Method may fail to close database resource on exception The method creates a database resource (such as a database connection or row set), does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the object on all exception paths out of the method. Failure to close database resources on all paths out of a method may result in poor performance, and could cause the application to have problems communicating with the database. OS: Method may fail to close stream The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close the stream on all paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed. OS: Method may fail to close stream on exception The method creates an IO stream object, does not assign it to any fields, pass it to other methods, or return it, and does not appear to close it on all possible exception paths out of the method. This may result in a file descriptor leak. It is generally a good idea to use a finally block to ensure that streams are closed. PZLA: Consider returning a zero length array rather than null It is often a better design to return a length zero array rather than a null reference to indicate that there are no results (i.e., an empty list of results). This way, no explicit check for null is needed by clients of the method. On the otherhand, using null to indicate "there is no answer to this question", then it is probably appropriate. For example, File.listFiles returns an empty list if given a directory containing no files, and returns null if the file is not a directory. RC: Suspicious reference comparison This method compares two reference values using the == or != operator, where the correct way to compare instances of this type is generally with the equals method. Examples of classes which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc. RCN: Redundant comparision to null of previously checked value This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported: Both values compared are definitely null · One value is definitely null and the other is definitely not null · This particular warning generally indicates that a value known not to be null was checked against null. While the check is not necessary, it may simply be a case of defensive programming. RCN: Redundant comparison to null This method contains a redundant comparison of a reference value to null. Two types of redundant comparison are reported: Both values compared are definitely null · One value is definitely null and the other is definitely not null · This particular warning represents two specific kinds of redundant comparisions: 1. A value was dereferenced, and later explicitly compared to null: this often indicates an error in the method 2. A literal null value was explicitly compared to null: this may indicate th。