Findbugs缺陷等級(jí)對(duì)照表

1、FindBugs Bug DescriptionsThis document lists the standard bug patterns reported by version 0.8.5.Summary序號(hào)等級(jí)DescriptionCategory14AEC: Call to equals() with null argumentCorrectness調(diào)用Equal方法的參數(shù)為空15AEC: Call to equals() comparing differentCorrectnessinterface types調(diào)用Equal方法去比較不同的接口類型16AEC: Call to equ

2、als() comparing differentCorrectnesstypes調(diào)用Equal方法去比較不同的數(shù)據(jù)類型17AES: Comparison of String objects using =Correctnessor !=使用=或者！=去比較字符申或?qū)ο?9BIJU: TestCase implements setUp but doesn'tCorrectnesscall super.setUp()測(cè)試實(shí)例實(shí)現(xiàn)了 setUp ()但沒有調(diào)用super.setUp()36ANP: Null pointer dereference in methodCorrectness方

3、法中存在空指針37ANP: Null pointer dereference in method onCorrectnessexception path方法中存在某異常路徑中的空指針38ANP: Possible null pointer dereference inCorrectnessmethod方法中存在可能在運(yùn)行時(shí)出現(xiàn)的空指針異常3941CorrectnessCorrectnessNP: Possible null pointer dereference in method on exception path方法中存在可能在某些異常路徑下出現(xiàn)的空指針異 常Nm: Class defin

4、es equal(); should it be equals。？類中定義了 equal方法，但是沒有重寫java.lang.Object 中equal方法，這也有可能是有意這么做的42Nm: Confusing method names一些方法名只有大小寫的區(qū)別，容易混繞Correctness43Nm: Confusing method name方法名和其超類的類名相同Nm: Class defines hashcode(); should it behashCode()?44類中定義了 hashCode()方法，但是沒有重寫 ava.lang.Object 中的hashCode()方法，這

5、也有可能是 有意這么做的Nm: Class defines tostring(); should it betoString()?CorrectnessCorrectness45類中定義了 tostring()方法，但是沒有重寫java.lang.Object 中的tostring() 方法，這也有可能是有意這么做的Correctness46Nm: Very confusing method names一些方法名只有大小寫的區(qū)別，特別容易混繞Correctness47ODR: Method may fail to close database resource方法可能沒有關(guān)閉數(shù)據(jù)源Correc

6、tness48ODR: Method may fail to close database resource on exceptionCorrectness49方法在異常時(shí)可能無法關(guān)閉數(shù)據(jù)源OS: Method may fail to close stream方法可能沒有關(guān)閉流Correctness50OS: Method may fail to close stream on exceptionCorrectness53方法在異常時(shí)可能無法關(guān)閉流RCN: Redundant comparision to null of previously checked value預(yù)測(cè)值的幾個(gè)比較的值中有

7、null值Correctness54 CRCN: Redundant comparison to null幾個(gè)比較的值中有null值Correctness57RV: Method ignores return value方法忽略了返回值Correctness59SI: Static initializer for class creates instance before all static final fields assigned類的靜態(tài)初始化器實(shí)例化一個(gè)該類對(duì)象要在所有的 常量屆性定義之前Correctness72 CUwF: Unwritten field永遠(yuǎn)不會(huì)寫到的字段，所有讀取

8、將返回默認(rèn)值Correctness83MS: Field isn't final but should be字段應(yīng)該為常量的卻不是常量Malicious code vulnerability86IS2: Inconsistent synchronization類中字段訪問不同步Multithreaded correctness88ML: Method synchronizes on an updated field方法從一個(gè)可變字段對(duì)象的引用中同步。這是不太能有用的，因?yàn)椴煌木€程可以在不同的對(duì)象上 同步。Multithreaded correctness92Ru: Invokes r

9、un on a thread (did you mean to start it instead?) AlZ當(dāng)一個(gè)類繼承Runnable接口時(shí)候，還去調(diào)用run方 法，實(shí)際上只需要調(diào)用Start方法就可以啟動(dòng)新的 線程，Multithreaded correctness93 CSC: Constructor invokes Thread.start() 構(gòu)造函數(shù)調(diào)用Thread.start102103()Dm: Method invokes dubious newString(String) constructor; just use the argument方法中調(diào)用String的構(gòu)造函數(shù)來

10、新建一個(gè)字符 申，直接使用其參數(shù)即可Dm: Method invokes dubiousString.equals(""); use String.length() = 0 insteadMultithreaded correctnessPerformancePerformance方法中調(diào)用了不確定的String.equals(""),使用String.length() = 0 來代替Dm: Method invokes toString() method on a104PerformanceString; just use the String方法中用

11、一個(gè)字符申去調(diào)用方法toString (),用105PerformanceString就可以了106CFI: Empty finalizer should be deletedPerformance空finalizer()方法是沒有用的，所以應(yīng)該予以刪除114CUPM: Private method is never calledPerformance這個(gè)私有方法從來沒有被調(diào)用到115CUrF: Unread field讀不到的字段，應(yīng)該從類中刪除Performance116CUuF: Unused fieldPerformanceDm: Method invokes dubious new

12、String() constructor; just use ""方法中新建一個(gè)空字符申用new String ()。直接 用就可以了讀不到的字段，應(yīng)該從類中刪除DescriptionsAM: Creates an empty jar file entryThe code calls putNextEntry() , immediately followed by a call to cioseEntry() . This results in an empty JarFile entry. The contents of the entry should be writt

13、en to the JarFile between the calls to putNextEntry() and closeEntry() .AM: Creates an empty zip file entryThe 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 c

14、alls to putNextEntry() and closeEntry().BIT: Incompatible bit masksThis 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 masksThis method compar

15、es 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 masksThis 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

16、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 wronglyThis method

17、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 0A call t

18、o 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 methodClass implements Cloneable but does not define or use the clone method.CN: clone met

19、hod 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 thatBsclone() method will return an object of typeA w

20、hich violates thestandard 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 definedThis class defines a covariant version ofcompareTo() . To correctlyover

21、ride the compareTo() method in the Comparable interface, the parameter of compareTo() must have type java.lang.Object .DE: Method might drop exceptionThis 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:

22、Method might ignore exceptionThis method might ignore an exception.In general, exceptions shouldbe 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

23、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 argumentThis method calls equals(Object), passing a null value as the argument. According to the contract of the equals

24、() method, this call should always return false .EC: Call to equals() comparing different interface typesThis 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 alw

25、ays 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 typesThis method calls equals(Object) on two references of different typ

26、es.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

27、 equality using the = or != operators. Unless both strings are either constants in a source file, or have been interned using theSern() method, thesame string value may be represented by two different String objects.Consider using the equals(Object) method instead.Eq: Covariant equals() met

28、hod definedThis class defines a covariant version ofequals() . To correctlyoverride theequals。 method in java.lang.Object , the parameter of equals。must have type java.lang.ObjectEq: Covariant equals() method defined, Object.equals(Object)inheritedThis class defines a covariant version of theequals。

29、 method, but callsthe 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 signaturebooleanequals(java.lang.Object) .FI: Explicit invocation of finalizerThis method contains an explicit

30、 invocation of thefinalize。method onan 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 finalizerThis finalize() method does not make a call to its superclass'sfinalize()method. So, any finalizer act

31、ions defined for the superclass will not be performed. Add a call to super.finalize() .FI: Finalizer nullifies superclass finalizerThis empty finalize。method explicitly negates the effect of anyfinalizer defined by its superclass.Any finalizer actions definedfor the superclass will not be performed.

32、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.hash

33、Code()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

34、 that equal objects must have equal hashcodes.hashCode()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 method to throw UnsupportedOperationExceptionHE: Class defines hashCode() but not equals()This class de

35、fines 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 de

36、fines 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

37、more complicated than simple reference equality.)HE: Class inherits equals() and uses Object.hashCode()This class inheritsequals(Object) from an abstract superclass, andhashCode() from from java.lang.Object (which returns the identity hash code, an arbitrary value assigned to the object by theVM). T

38、herefore, 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 thehashCode()method to throw UnsupportedOperationException

39、IC: Initialization circularityA circularity was detected in the static initializers of the two classes referenced by the bug instance.Many kinds of unexpectedbehavior may arise from such circularity.IJU: TestCase implements setUp but doesn't call super.setUp()Class is a JUnit TestCase and implem

40、ents the setUp method. The setUp method should call super.setUp(), but doesn't.IMSE: Dubious catching of IllegalMonitorStateExceptionIllegalMonitorStateException 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: Ite

41、rator next() method can't throw NoSuchElement exceptionThis 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

42、are no more elements to return.MF: Class defines field that obscures a superclass fieldThis 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:

43、Method defines a variable that obscures a fieldThis 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 O

44、bject.notify() or Object.notifyAll() without obviously holding a lock on the object.Calling notify() ornotifyAll() 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. Cal

45、ling wait() without a lock held will result in an IllegalMonitorStateException being thrown.NP: Null pointer dereference in methodA null pointer is dereferenced here.This will lead to aNullPointerException when the code is executed.NP: Null pointer dereference in method on exception pathA pointer wh

46、ich 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 pruneinfeasible exception paths, this may be a false warning.Also note that FindBugs considers the default case of a switch stateme

47、nt to be an exception path, since the default case is often infeasible.NP: Possible null pointer dereference in methodA reference value dereferenced here might be null at runtime.Thismay lead to a NullPointerException when the code is executed.NP: Possible null pointer dereference in method on excep

48、tion pathA 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 conside

49、rs 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 logicThis code seems to be using non-short-circuit logic (e.g., & or |) rather than short-circuit logic (&& or |). Non-short-circuit log

50、ic 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(); sho

51、uld 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 namesThe referenced methods have names that differ only by capitalization.Nm: Confusing method nameThis

52、 method has the same name as the superclass of the class it isdefined 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 defin

53、es 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 namesThe referenced methods have names that differ only by capitalization.ODR

54、: Method may fail to close database resourceThe 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 r

55、esources 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 exceptionThe method creates a database resource (such as a database connection or row set), does n

56、ot 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 databaseresources on all paths out of a method may result in poor performance, and could cause the application to have problems commun

57、icating with the database.OS: Method may fail to close streamThe 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 afile descriptor leak.It is generally a good idea to use afinallyblock to ensure that streams are closed.OS: Method may fail to close stream on exceptionThe method creates an IO stream object, does not assign it to any fields, pas