Divide Error Null Pointer Assignment Java

FindBugs Bug Descriptions

This document lists the standard bug patterns reported by FindBugs version 3.0.1.

Summary

DescriptionCategory
BC: Equals method should not assume anything about the type of its argumentBad practice
BIT: Check for sign of bitwise operationBad practice
CN: Class implements Cloneable but does not define or use clone methodBad practice
CN: clone method does not call super.clone()Bad practice
CN: Class defines clone() but doesn't implement CloneableBad practice
CNT: Rough value of known constant foundBad practice
Co: Abstract class defines covariant compareTo() methodBad practice
Co: compareTo()/compare() incorrectly handles float or double valueBad practice
Co: compareTo()/compare() returns Integer.MIN_VALUEBad practice
Co: Covariant compareTo() method definedBad practice
DE: Method might drop exceptionBad practice
DE: Method might ignore exceptionBad practice
DMI: Adding elements of an entry set may fail due to reuse of Entry objectsBad practice
DMI: Random object created and used only onceBad practice
DMI: Don't use removeAll to clear a collectionBad practice
Dm: Method invokes System.exit(...)Bad practice
Dm: Method invokes dangerous method runFinalizersOnExitBad practice
ES: Comparison of String parameter using == or !=Bad practice
ES: Comparison of String objects using == or !=Bad practice
Eq: Abstract class defines covariant equals() methodBad practice
Eq: Equals checks for incompatible operandBad practice
Eq: Class defines compareTo(...) and uses Object.equals()Bad practice
Eq: equals method fails for subtypesBad practice
Eq: Covariant equals() method definedBad practice
FI: Empty finalizer should be deletedBad practice
FI: Explicit invocation of finalizerBad practice
FI: Finalizer nulls fieldsBad practice
FI: Finalizer only nulls fieldsBad practice
FI: Finalizer does not call superclass finalizerBad practice
FI: Finalizer nullifies superclass finalizerBad practice
FI: Finalizer does nothing but call superclass finalizerBad practice
FS: Format string should use %n rather than \nBad practice
GC: Unchecked type in generic callBad practice
HE: Class defines equals() but not hashCode()Bad practice
HE: Class defines equals() and uses Object.hashCode()Bad practice
HE: Class defines hashCode() but not equals()Bad practice
HE: Class defines hashCode() and uses Object.equals()Bad practice
HE: Class inherits equals() and uses Object.hashCode()Bad practice
IC: Superclass uses subclass during initializationBad practice
IMSE: Dubious catching of IllegalMonitorStateExceptionBad practice
ISC: Needless instantiation of class that only supplies static methodsBad practice
It: Iterator next() method can't throw NoSuchElementExceptionBad practice
J2EE: Store of non serializable object into HttpSessionBad practice
JCIP: Fields of immutable classes should be finalBad practice
ME: Public enum method unconditionally sets its fieldBad practice
ME: Enum field is public and mutableBad practice
NP: Method with Boolean return type returns explicit nullBad practice
NP: Clone method may return nullBad practice
NP: equals() method does not check for null argumentBad practice
NP: toString method may return nullBad practice
Nm: Class names should start with an upper case letterBad practice
Nm: Class is not derived from an Exception, even though it is named as suchBad practice
Nm: Confusing method namesBad practice
Nm: Field names should start with a lower case letterBad practice
Nm: Use of identifier that is a keyword in later versions of JavaBad practice
Nm: Use of identifier that is a keyword in later versions of JavaBad practice
Nm: Method names should start with a lower case letterBad practice
Nm: Class names shouldn't shadow simple name of implemented interfaceBad practice
Nm: Class names shouldn't shadow simple name of superclassBad practice
Nm: Very confusing method names (but perhaps intentional)Bad practice
Nm: Method doesn't override method in superclass due to wrong package for parameterBad practice
ODR: Method may fail to close database resourceBad practice
ODR: Method may fail to close database resource on exceptionBad practice
OS: Method may fail to close streamBad practice
OS: Method may fail to close stream on exceptionBad practice
PZ: Don't reuse entry objects in iteratorsBad practice
RC: Suspicious reference comparison to constantBad practice
RC: Suspicious reference comparison of Boolean valuesBad practice
RR: Method ignores results of InputStream.read()Bad practice
RR: Method ignores results of InputStream.skip()Bad practice
RV: Negating the result of compareTo()/compare()Bad practice
RV: Method ignores exceptional return valueBad practice
SI: Static initializer creates instance before all static final fields assignedBad practice
SW: Certain swing methods needs to be invoked in Swing threadBad practice
Se: Non-transient non-serializable instance field in serializable classBad practice
Se: Non-serializable class has a serializable inner classBad practice
Se: Non-serializable value stored into instance field of a serializable classBad practice
Se: Comparator doesn't implement SerializableBad practice
Se: Serializable inner classBad practice
Se: serialVersionUID isn't finalBad practice
Se: serialVersionUID isn't longBad practice
Se: serialVersionUID isn't staticBad practice
Se: Class is Serializable but its superclass doesn't define a void constructorBad practice
Se: Class is Externalizable but doesn't define a void constructorBad practice
Se: The readResolve method must be declared with a return type of Object. Bad practice
Se: Transient field that isn't set by deserialization. Bad practice
SnVI: Class is Serializable, but doesn't define serialVersionUIDBad practice
UI: Usage of GetResource may be unsafe if class is extendedBad practice
BC: Impossible castCorrectness
BC: Impossible downcastCorrectness
BC: Impossible downcast of toArray() resultCorrectness
BC: instanceof will always return falseCorrectness
BIT: Bitwise add of signed byte valueCorrectness
BIT: Incompatible bit masksCorrectness
BIT: Check to see if ((...) & 0) == 0Correctness
BIT: Incompatible bit masksCorrectness
BIT: Bitwise OR of signed byte valueCorrectness
BIT: Check for sign of bitwise operationCorrectness
BOA: Class overrides a method implemented in super class Adapter wronglyCorrectness
BSHIFT: Possible bad parsing of shift operationCorrectness
BSHIFT: 32 bit int shifted by an amount not in the range -31..31Correctness
DLS: Useless increment in return statementCorrectness
DLS: Dead store of class literalCorrectness
DLS: Overwritten incrementCorrectness
DMI: Reversed method argumentsCorrectness
DMI: Bad constant value for monthCorrectness
DMI: BigDecimal constructed from double that isn't represented preciselyCorrectness
DMI: hasNext method invokes nextCorrectness
DMI: Collections should not contain themselvesCorrectness
DMI: D'oh! A nonsensical method invocationCorrectness
DMI: Invocation of hashCode on an arrayCorrectness
DMI: Double.longBitsToDouble invoked on an intCorrectness
DMI: Vacuous call to collectionsCorrectness
Dm: Can't use reflection to check for presence of annotation without runtime retentionCorrectness
Dm: Futile attempt to change max pool size of ScheduledThreadPoolExecutorCorrectness
Dm: Creation of ScheduledThreadPoolExecutor with zero core threadsCorrectness
Dm: Useless/vacuous call to EasyMock methodCorrectness
Dm: Incorrect combination of Math.max and Math.minCorrectness
EC: equals() used to compare array and nonarrayCorrectness
EC: Invocation of equals() on an array, which is equivalent to ==Correctness
EC: equals(...) used to compare incompatible arraysCorrectness
EC: Call to equals(null)Correctness
EC: Call to equals() comparing unrelated class and interfaceCorrectness
EC: Call to equals() comparing different interface typesCorrectness
EC: Call to equals() comparing different typesCorrectness
EC: Using pointer equality to compare different typesCorrectness
Eq: equals method always returns falseCorrectness
Eq: equals method always returns trueCorrectness
Eq: equals method compares class names rather than class objectsCorrectness
Eq: Covariant equals() method defined for enumCorrectness
Eq: equals() method defined that doesn't override equals(Object)Correctness
Eq: equals() method defined that doesn't override Object.equals(Object)Correctness
Eq: equals method overrides equals in superclass and may not be symmetricCorrectness
Eq: Covariant equals() method defined, Object.equals(Object) inheritedCorrectness
FE: Doomed test for equality to NaNCorrectness
FS: Format string placeholder incompatible with passed argumentCorrectness
FS: The type of a supplied argument doesn't match format specifierCorrectness
FS: MessageFormat supplied where printf style format expectedCorrectness
FS: More arguments are passed than are actually used in the format stringCorrectness
FS: Illegal format stringCorrectness
FS: Format string references missing argumentCorrectness
FS: No previous argument for format stringCorrectness
GC: No relationship between generic parameter and method argumentCorrectness
HE: Signature declares use of unhashable class in hashed constructCorrectness
HE: Use of class without a hashCode() method in a hashed data structureCorrectness
ICAST: int value converted to long and used as absolute timeCorrectness
ICAST: Integral value cast to double and then passed to Math.ceilCorrectness
ICAST: int value cast to float and then passed to Math.roundCorrectness
IJU: JUnit assertion in run method will not be noticed by JUnitCorrectness
IJU: TestCase declares a bad suite method Correctness
IJU: TestCase has no testsCorrectness
IJU: TestCase defines setUp that doesn't call super.setUp()Correctness
IJU: TestCase implements a non-static suite method Correctness
IJU: TestCase defines tearDown that doesn't call super.tearDown()Correctness
IL: A collection is added to itselfCorrectness
IL: An apparent infinite loopCorrectness
IL: An apparent infinite recursive loopCorrectness
IM: Integer multiply of result of integer remainderCorrectness
INT: Bad comparison of int value with long constantCorrectness
INT: Bad comparison of nonnegative value with negative constant or zeroCorrectness
INT: Bad comparison of signed byteCorrectness
IO: Doomed attempt to append to an object output streamCorrectness
IP: A parameter is dead upon entry to a method but overwrittenCorrectness
MF: Class defines field that masks a superclass fieldCorrectness
MF: Method defines a variable that obscures a fieldCorrectness
NP: Null pointer dereferenceCorrectness
NP: Null pointer dereference in method on exception pathCorrectness
NP: Method does not check for null argumentCorrectness
NP: close() invoked on a value that is always nullCorrectness
NP: Null value is guaranteed to be dereferencedCorrectness
NP: Value is null and guaranteed to be dereferenced on exception pathCorrectness
NP: Non-null field is not initializedCorrectness
NP: Method call passes null to a non-null parameter Correctness
NP: Method may return null, but is declared @NonnullCorrectness
NP: A known null value is checked to see if it is an instance of a typeCorrectness
NP: Possible null pointer dereferenceCorrectness
NP: Possible null pointer dereference in method on exception pathCorrectness
NP: Method call passes null for non-null parameterCorrectness
NP: Method call passes null for non-null parameterCorrectness
NP: Non-virtual method call passes null for non-null parameterCorrectness
NP: Method with Optional return type returns explicit nullCorrectness
NP: Store of null value into field annotated @NonnullCorrectness
NP: Read of unwritten fieldCorrectness
Nm: Class defines equal(Object); should it be equals(Object)?Correctness
Nm: Class defines hashcode(); should it be hashCode()?Correctness
Nm: Class defines tostring(); should it be toString()?Correctness
Nm: Apparent method/constructor confusionCorrectness
Nm: Very confusing method namesCorrectness
Nm: Method doesn't override method in superclass due to wrong package for parameterCorrectness
QBA: Method assigns boolean literal in boolean expressionCorrectness
RANGE: Array index is out of boundsCorrectness
RANGE: Array length is out of boundsCorrectness
RANGE: Array offset is out of boundsCorrectness
RANGE: String index is out of boundsCorrectness
RC: Suspicious reference comparisonCorrectness
RCN: Nullcheck of value previously dereferencedCorrectness
RE: Invalid syntax for regular expressionCorrectness
RE: File.separator used for regular expressionCorrectness
RE: "." or "|" used for regular expressionCorrectness
RV: Random value from 0 to 1 is coerced to the integer 0Correctness
RV: Bad attempt to compute absolute value of signed 32-bit hashcode Correctness
RV: Bad attempt to compute absolute value of signed random integerCorrectness
RV: Code checks for specific values returned by compareToCorrectness
RV: Exception created and dropped rather than thrownCorrectness
RV: Method ignores return valueCorrectness
RpC: Repeated conditional testsCorrectness
SA: Self assignment of fieldCorrectness
SA: Self comparison of field with itselfCorrectness
SA: Nonsensical self computation involving a field (e.g., x & x)Correctness
SA: Self assignment of local rather than assignment to fieldCorrectness
SA: Self comparison of value with itselfCorrectness
SA: Nonsensical self computation involving a variable (e.g., x & x)Correctness
SF: Dead store due to switch statement fall throughCorrectness
SF: Dead store due to switch statement fall through to throwCorrectness
SIC: Deadly embrace of non-static inner class and thread localCorrectness
SIO: Unnecessary type check done using instanceof operatorCorrectness
SQL: Method attempts to access a prepared statement parameter with index 0Correctness
SQL: Method attempts to access a result set field with index 0Correctness
STI: Unneeded use of currentThread() call, to call interrupted() Correctness
STI: Static Thread.interrupted() method invoked on thread instanceCorrectness
Se: Method must be private in order for serialization to workCorrectness
Se: The readResolve method must not be declared as a static method. Correctness
TQ: Value annotated as carrying a type qualifier used where a value that must not carry that qualifier is requiredCorrectness
TQ: Comparing values with incompatible type qualifiersCorrectness
TQ: Value that might not carry a type qualifier is always used in a way requires that type qualifierCorrectness
TQ: Value that might carry a type qualifier is always used in a way prohibits it from having that type qualifierCorrectness
TQ: Value annotated as never carrying a type qualifier used where value carrying that qualifier is requiredCorrectness
TQ: Value without a type qualifier used where a value is required to have that qualifierCorrectness
UMAC: Uncallable method defined in anonymous classCorrectness
UR: Uninitialized read of field in constructorCorrectness
UR: Uninitialized read of field method called from constructor of superclassCorrectness
USELESS_STRING: Invocation of toString on an unnamed arrayCorrectness
USELESS_STRING: Invocation of toString on an arrayCorrectness
USELESS_STRING: Array formatted in useless way using format stringCorrectness
UwF: Field only ever set to nullCorrectness
UwF: Unwritten fieldCorrectness
VA: Primitive array passed to function expecting a variable number of object argumentsCorrectness
LG: Potential lost logger changes due to weak reference in OpenJDKExperimental
OBL: Method may fail to clean up stream or resourceExperimental
OBL: Method may fail to clean up stream or resource on checked exceptionExperimental
Dm: Consider using Locale parameterized version of invoked methodInternationalization
Dm: Reliance on default encodingInternationalization
DP: Classloaders should only be created inside doPrivileged blockMalicious code vulnerability
DP: Method invoked that should be only be invoked inside a doPrivileged blockMalicious code vulnerability
EI: May expose internal representation by returning reference to mutable objectMalicious code vulnerability
EI2: May expose internal representation by incorporating reference to mutable objectMalicious code vulnerability
FI: Finalizer should be protected, not publicMalicious code vulnerability
MS: May expose internal static state by storing a mutable object into a static fieldMalicious code vulnerability
MS: Field isn't final and can't be protected from malicious codeMalicious code vulnerability
MS: Public static method may expose internal representation by returning arrayMalicious code vulnerability
MS: Field should be both final and package protectedMalicious code vulnerability
MS: Field is a mutable arrayMalicious code vulnerability
MS: Field is a mutable collectionMalicious code vulnerability
MS: Field is a mutable collection which should be package protectedMalicious code vulnerability
MS: Field is a mutable HashtableMalicious code vulnerability
MS: Field should be moved out of an interface and made package protectedMalicious code vulnerability
MS: Field should be package protectedMalicious code vulnerability
MS: Field isn't final but should beMalicious code vulnerability
MS: Field isn't final but should be refactored to be soMalicious code vulnerability
AT: Sequence of calls to concurrent abstraction may not be atomicMultithreaded correctness
DC: Possible double check of fieldMultithreaded correctness
DC: Possible exposure of partially initialized objectMultithreaded correctness
DL: Synchronization on BooleanMultithreaded correctness
DL: Synchronization on boxed primitiveMultithreaded correctness
DL: Synchronization on interned String Multithreaded correctness
DL: Synchronization on boxed primitive valuesMultithreaded correctness
Dm: Monitor wait() called on ConditionMultithreaded correctness
Dm: A thread was created using the default empty run methodMultithreaded correctness
ESync: Empty synchronized blockMultithreaded correctness
IS: Inconsistent synchronizationMultithreaded correctness
IS: Field not guarded against concurrent accessMultithreaded correctness
JLM: Synchronization performed on LockMultithreaded correctness
JLM: Synchronization performed on util.concurrent instanceMultithreaded correctness
JLM: Using monitor style wait methods on util.concurrent abstractionMultithreaded correctness
LI: Incorrect lazy initialization of static fieldMultithreaded correctness
LI: Incorrect lazy initialization and update of static fieldMultithreaded correctness
ML: Synchronization on field in futile attempt to guard that fieldMultithreaded correctness
ML: Method synchronizes on an updated fieldMultithreaded correctness
MSF: Mutable servlet fieldMultithreaded correctness
MWN: Mismatched notify()Multithreaded correctness
MWN: Mismatched wait()Multithreaded correctness
NN: Naked notifyMultithreaded correctness
NP: Synchronize and null check on the same field.Multithreaded correctness
No: Using notify() rather than notifyAll()Multithreaded correctness
RS: Class's readObject() method is synchronizedMultithreaded correctness
RV: Return value of putIfAbsent ignored, value passed to putIfAbsent reusedMultithreaded correctness
Ru: Invokes run on a thread (did you mean to start it instead?)Multithreaded correctness
SC: Constructor invokes Thread.start()Multithreaded correctness
SP: Method spins on fieldMultithreaded correctness
STCAL: Call to static CalendarMultithreaded correctness
STCAL: Call to static DateFormatMultithreaded correctness
STCAL: Static Calendar fieldMultithreaded correctness
STCAL: Static DateFormatMultithreaded correctness
SWL: Method calls Thread.sleep() with a lock heldMultithreaded correctness
TLW: Wait with two locks heldMultithreaded correctness
UG: Unsynchronized get method, synchronized set methodMultithreaded correctness
UL: Method does not release lock on all pathsMultithreaded correctness
UL: Method does not release lock on all exception pathsMultithreaded correctness
UW: Unconditional waitMultithreaded correctness
VO: An increment to a volatile field isn't atomicMultithreaded correctness
VO: A volatile reference to an array doesn't treat the array elements as volatileMultithreaded correctness
WL: Synchronization on getClass rather than class literalMultithreaded correctness
WS: Class's writeObject() method is synchronized but nothing else isMultithreaded correctness
Wa: Condition.await() not in loop Multithreaded correctness
Wa: Wait not in loop Multithreaded correctness
Bx: Primitive value is boxed and then immediately unboxedPerformance
Bx: Primitive value is boxed then unboxed to perform primitive coercionPerformance
Bx: Primitive value is unboxed and coerced for ternary operatorPerformance
Bx: Boxed value is unboxed and then immediately reboxedPerformance
Bx: Boxing a primitive to comparePerformance
Bx: Boxing/unboxing to parse a primitivePerformance
Bx: Method allocates a boxed primitive just to call toStringPerformance
Bx: Method invokes inefficient floating-point Number constructor; use static valueOf insteadPerformance
Bx: Method invokes inefficient Number constructor; use static valueOf insteadPerformance
Dm: The equals and hashCode methods of URL are blockingPerformance
Dm: Maps and sets of URLs can be performance hogsPerformance
Dm: Method invokes inefficient Boolean constructor; use Boolean.valueOf(...) insteadPerformance
Dm: Explicit garbage collection; extremely dubious except in benchmarking codePerformance
Dm: Method allocates an object, only to get the class objectPerformance
Dm: Use the nextInt method of Random rather than nextDouble to generate a random integerPerformance
Dm: Method invokes inefficient new String(String) constructorPerformance
Dm: Method invokes toString() method on a StringPerformance
Dm: Method invokes inefficient new String() constructorPerformance
HSC: Huge string constants is duplicated across multiple class filesPerformance
SBSC: Method concatenates strings using + in a loopPerformance
SIC: Should be a static inner classPerformance
SIC: Could be refactored into a named static inner classPerformance
SIC: Could be refactored into a static inner classPerformance
SS: Unread field: should this field be static?Performance
UM: Method calls static Math class method on a constant valuePerformance
UPM: Private method is never calledPerformance
UrF: Unread fieldPerformance
UuF: Unused fieldPerformance
WMI: Inefficient use of keySet iterator instead of entrySet iteratorPerformance
Dm: Hardcoded constant database passwordSecurity
Dm: Empty database passwordSecurity
HRS: HTTP cookie formed from untrusted inputSecurity
HRS: HTTP Response splitting vulnerabilitySecurity
PT: Absolute path traversal in servletSecurity
PT: Relative path traversal in servletSecurity
SQL: Nonconstant string passed to execute or addBatch method on an SQL statementSecurity
SQL: A prepared statement is generated from a nonconstant StringSecurity
XSS: JSP reflected cross site scripting vulnerabilitySecurity
XSS: Servlet reflected cross site scripting vulnerability in error pageSecurity
XSS: Servlet reflected cross site scripting vulnerabilitySecurity
BC: Questionable cast to abstract collection Dodgy code
BC: Questionable cast to concrete collectionDodgy code
BC: Unchecked/unconfirmed castDodgy code
BC: Unchecked/unconfirmed cast of return value from methodDodgy code
BC: instanceof will always return trueDodgy code
BSHIFT: Unsigned right shift cast to short/byteDodgy code
CI: Class is final but declares protected fieldDodgy code
DB: Method uses the same code for two branchesDodgy code
DB: Method uses the same code for two switch clausesDodgy code
DLS: Dead store to local variableDodgy code
DLS: Useless assignment in return statementDodgy code
DLS: Dead store of null to local variableDodgy code
DLS: Dead store to local variable that shadows fieldDodgy code
DMI: Code contains a hard coded reference to an absolute pathnameDodgy code
DMI: Non serializable object written to ObjectOutputDodgy code
DMI: Invocation of substring(0), which returns the original valueDodgy code
Dm: Thread passed where Runnable expectedDodgy code
Eq: Class doesn't override equals in superclassDodgy code
Eq: Unusual equals method Dodgy code
FE: Test for floating point equalityDodgy code
FS: Non-Boolean argument formatted using %b format specifierDodgy code
IA: Potentially ambiguous invocation of either an inherited or outer methodDodgy code
IC: Initialization circularityDodgy code
ICAST: Integral division result cast to double or floatDodgy code
ICAST: Result of integer multiplication cast to longDodgy code
IM: Computation of average could overflowDodgy code
IM: Check for oddness that won't work for negative numbers Dodgy code
INT: Integer remainder modulo 1Dodgy code
INT: Vacuous bit mask operation on integer valueDodgy code
INT: Vacuous comparison of integer valueDodgy code
MTIA: Class extends Servlet class and uses instance variablesDodgy code
MTIA: Class extends Struts Action class and uses instance variablesDodgy code
NP: Dereference of the result of readLine() without nullcheckDodgy code
NP: Immediate dereference of the result of readLine()Dodgy code
NP: Load of known null valueDodgy code
NP: Method tightens nullness annotation on parameterDodgy code
NP: Method relaxes nullness annotation on return valueDodgy code
NP: Possible null pointer dereference due to return value of called methodDodgy code
NP: Possible null pointer dereference on branch that might be infeasibleDodgy code
NP: Parameter must be non-null but is marked as nullableDodgy code
NP: Read of unwritten public or protected fieldDodgy code
NS: Potentially dangerous use of non-short-circuit logicDodgy code
NS: Questionable use of non-short-circuit logicDodgy code
PZLA: Consider returning a zero length array rather than nullDodgy code
QF: Complicated, subtle or wrong increment in for-loop Dodgy code
RCN: Redundant comparison of non-null value to nullDodgy code
RCN: Redundant comparison of two null valuesDodgy code
RCN: Redundant nullcheck of value known to be non-nullDodgy code
RCN: Redundant nullcheck of value known to be nullDodgy code
REC: Exception is caught when Exception is not thrownDodgy code
RI: Class implements same interface as superclassDodgy code
RV: Method checks to see if result of String.indexOf is positiveDodgy code
RV: Method discards result of readLine after checking if it is non-nullDodgy code
RV: Remainder of hashCode could be negativeDodgy code
RV: Remainder of 32-bit signed random integerDodgy code
RV: Method ignores return value, is this OK?Dodgy code
RV: Return value of method without side effect is ignoredDodgy code
SA: Double assignment of fieldDodgy code
SA: Double assignment of local variable Dodgy code
SA: Self assignment of local variableDodgy code
SF: Switch statement found where one case falls through to the next caseDodgy code
SF: Switch statement found where default case is missingDodgy code
ST: Write to static field from instance methodDodgy code
Se: Private readResolve method not inherited by subclassesDodgy code
Se: Transient field of class that isn't Serializable. Dodgy code
TQ: Value required to have type qualifier, but marked as unknownDodgy code
TQ: Value required to not have type qualifier, but marked as unknownDodgy code
UC: Condition has no effectDodgy code
UC: Condition has no effect due to the variable typeDodgy code
UC: Useless object createdDodgy code
UC: Useless object created on stackDodgy code
UC: Useless non-empty void methodDodgy code
UCF: Useless control flowDodgy code
UCF: Useless control flow to next lineDodgy code
UrF: Unread public/protected fieldDodgy code
UuF: Unused public or protected fieldDodgy code
UwF: Field not initialized in constructor but dereferenced without null checkDodgy code
UwF: Unwritten public or protected fieldDodgy code
XFB: Method directly allocates a specific implementation of xml interfacesDodgy code

Descriptions

BC: Equals method should not assume anything about the type of its argument (BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS)

The method shouldn't make any assumptions about the type of . It should simply return false if is not the same type as .

BIT: Check for sign of bitwise operation (BIT_SIGNED_CHECK)

This method compares an expression such as

((event.detail & SWT.SELECTED) > 0).

Using bit arithmetic and then comparing with the greater than operator can lead to unexpected results (of course depending on the value of SWT.SELECTED). If SWT.SELECTED is a negative number, this is a candidate for a bug. Even when SWT.SELECTED is not negative, it seems good practice to use '!= 0' instead of '> 0'.

Boris Bokowski

CN: Class implements Cloneable but does not define or use clone method (CN_IDIOM)

Class implements Cloneable but does not define or use the clone method.

CN: clone method does not call super.clone() (CN_IDIOM_NO_SUPER_CALL)

This non-final class defines a clone() method that does not call super.clone(). 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.

CN: Class defines clone() but doesn't implement Cloneable (CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE)

This class defines a clone() method but the class doesn't implement Cloneable. There are some situations in which this is OK (e.g., you want to control how subclasses can clone themselves), but just make sure that this is what you intended.

CNT: Rough value of known constant found (CNT_ROUGH_CONSTANT_VALUE)

It's recommended to use the predefined library constant for code clarity and better precision.

Co: Abstract class defines covariant compareTo() method (CO_ABSTRACT_SELF)

This class defines a covariant version of .  To correctly override the method in the interface, the parameter of must have type .

Co: compareTo()/compare() incorrectly handles float or double value (CO_COMPARETO_INCORRECT_FLOATING)

This method compares double or float values using pattern like this: val1 > val2 ? 1 : val1 < val2 ? -1 : 0. This pattern works incorrectly for -0.0 and NaN values which may result in incorrect sorting result or broken collection (if compared values are used as keys). Consider using Double.compare or Float.compare static methods which handle all the special cases correctly.

Co: compareTo()/compare() returns Integer.MIN_VALUE (CO_COMPARETO_RESULTS_MIN_VALUE)

In some situation, this compareTo or compare method returns the constant Integer.MIN_VALUE, which is an exceptionally bad practice. The only thing that matters about the return value of compareTo is the sign of the result. But people will sometimes negate the return value of compareTo, expecting that this will negate the sign of the result. And it will, except in the case where the value returned is Integer.MIN_VALUE. So just return -1 rather than Integer.MIN_VALUE.

Co: Covariant compareTo() method defined (CO_SELF_NO_OBJECT)

This class defines a covariant version of .  To correctly override the method in the interface, the parameter of must have type .

DE: Method might drop exception (DE_MIGHT_DROP)

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 (DE_MIGHT_IGNORE)

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.

DMI: Adding elements of an entry set may fail due to reuse of Entry objects (DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS)

The entrySet() method is allowed to return a view of the underlying Map in which a single Entry object is reused and returned during the iteration. As of Java 1.6, both IdentityHashMap and EnumMap did so. When iterating through such a Map, the Entry value is only valid until you advance to the next iteration. If, for example, you try to pass such an entrySet to an addAll method, things will go badly wrong.

DMI: Random object created and used only once (DMI_RANDOM_USED_ONLY_ONCE)

This code creates a java.util.Random object, uses it to generate one random number, and then discards the Random object. This produces mediocre quality random numbers and is inefficient. If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number is required invoke a method on the existing Random object to obtain it.

If it is important that the generated Random numbers not be guessable, you must not create a new Random for each random number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead (and avoid allocating a new SecureRandom for each random number needed).

DMI: Don't use removeAll to clear a collection (DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION)

If you want to remove all elements from a collection , use , not . Calling to clear a collection is less clear, susceptible to errors from typos, less efficient and for some collections, might throw a .

Dm: Method invokes System.exit(...) (DM_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.

Dm: Method invokes dangerous method runFinalizersOnExit (DM_RUN_FINALIZERS_ON_EXIT)

Never call System.runFinalizersOnExit or Runtime.runFinalizersOnExit for any reason: they are among the most dangerous methods in the Java libraries. -- Joshua Bloch

ES: Comparison of String parameter using == or != (ES_COMPARING_PARAMETER_STRING_WITH_EQ)

This code compares a parameter for reference equality using the == or != operators. Requiring callers to pass only String constants or interned strings to a method is unnecessarily fragile, and rarely leads to measurable performance gains. Consider using the method instead.

ES: Comparison of String objects using == or != (ES_COMPARING_STRINGS_WITH_EQ)

This code compares objects for reference equality using the == or != operators. Unless both strings are either constants in a source file, or have been interned using the method, the same string value may be represented by two different String objects. Consider using the method instead.

Eq: Abstract class defines covariant equals() method (EQ_ABSTRACT_SELF)

This class defines a covariant version of .  To correctly override the method in , the parameter of must have type .

Eq: Equals checks for incompatible operand (EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS)

This equals method is checking to see if the argument is some incompatible type (i.e., a class that is neither a supertype nor subtype of the class that defines the equals method). For example, the Foo class might have an equals method that looks like:

public boolean equals(Object o) { if (o instanceof Foo) return name.equals(((Foo)o).name); else if (o instanceof String) return name.equals(o); else return false;

This is considered bad practice, as it makes it very hard to implement an equals method that is symmetric and transitive. Without those properties, very unexpected behavoirs are possible.

Eq: Class defines compareTo(...) and uses Object.equals() (EQ_COMPARETO_USE_OBJECT_EQUALS)

This class defines a method but inherits its method from . Generally, the value of compareTo should return zero if and only if equals returns true. If this is violated, weird and unpredictable failures will occur in classes such as PriorityQueue. In Java 5 the PriorityQueue.remove method uses the compareTo method, while in Java 6 it uses the equals method.

From the JavaDoc for the compareTo method in the Comparable interface:

It is strongly recommended, but not strictly required that . Generally speaking, any class that implements the Comparable interface and violates this condition should clearly indicate this fact. The recommended language is "Note: this class has a natural ordering that is inconsistent with equals."

Eq: equals method fails for subtypes (EQ_GETCLASS_AND_CLASS_CONSTANT)

This class has an equals method that will be broken if it is inherited by subclasses. It compares a class literal with the class of the argument (e.g., in class it might check if ). It is better to check if .

Eq: Covariant equals() method defined (EQ_SELF_NO_OBJECT)

This class defines a covariant version of .  To correctly override the method in , the parameter of must have type .

FI: Empty finalizer should be deleted (FI_EMPTY)

Empty methods are useless, so they should be deleted.

FI: Explicit invocation of finalizer (FI_EXPLICIT_INVOCATION)

This method contains an explicit invocation of the method on an object.  Because finalizer methods are supposed to be executed once, and only by the VM, this is a bad idea.

If a connected set of objects beings finalizable, then the VM will invoke the finalize method on all the finalizable object, possibly at the same time in different threads. Thus, it is a particularly bad idea, in the finalize method for a class X, invoke finalize on objects referenced by X, because they may already be getting finalized in a separate thread.

FI: Finalizer nulls fields (FI_FINALIZER_NULLS_FIELDS)

This finalizer nulls out fields. This is usually an error, as it does not aid garbage collection, and the object is going to be garbage collected anyway.

FI: Finalizer only nulls fields (FI_FINALIZER_ONLY_NULLS_FIELDS)

This finalizer does nothing except null out fields. This is completely pointless, and requires that the object be garbage collected, finalized, and then garbage collected again. You should just remove the finalize method.

FI: Finalizer does not call superclass finalizer (FI_MISSING_SUPER_CALL)

This method does not make a call to its superclass's method.  So, any finalizer actions defined for the superclass will not be performed.  Add a call to .

FI: Finalizer nullifies superclass finalizer (FI_NULLIFY_SUPER)

This empty 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.

FI: Finalizer does nothing but call superclass finalizer (FI_USELESS)

The only thing this method does is call the superclass's method, making it redundant.  Delete it.

FS: Format string should use %n rather than \n (VA_FORMAT_STRING_USES_NEWLINE)

This format string include a newline character (\n). In format strings, it is generally preferable better to use %n, which will produce the platform-specific line separator.

GC: Unchecked type in generic call (GC_UNCHECKED_TYPE_IN_GENERIC_CALL)

This call to a generic collection method passes an argument while compile type Object where a specific type from the generic type parameters is expected. Thus, neither the standard Java type system nor static analysis can provide useful information on whether the object being passed as a parameter is of an appropriate type.

HE: Class defines equals() but not hashCode() (HE_EQUALS_NO_HASHCODE)

This class overrides , but does not override .  Therefore, the class may violate the invariant that equal objects must have equal hashcodes.

HE: Class defines equals() and uses Object.hashCode() (HE_EQUALS_USE_HASHCODE)

This class overrides , but does not override , and inherits the implementation of from (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 think instances of this class will ever be inserted into a HashMap/HashTable, the recommended implementation to use is:

public int hashCode() { assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

HE: Class defines hashCode() but not equals() (HE_HASHCODE_NO_EQUALS)

This class defines a method but not an method.  Therefore, the class may violate the invariant that equal objects must have equal hashcodes.

HE: Class defines hashCode() and uses Object.equals() (HE_HASHCODE_USE_OBJECT_EQUALS)

This class defines a method but inherits its method from (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 method.  (Overriding implies that the object's identity is based on criteria more complicated than simple reference equality.)

If you don't think instances of this class will ever be inserted into a HashMap/HashTable, the recommended implementation to use is:

public int hashCode() { assert false : "hashCode not designed"; return 42; // any arbitrary constant will do }

HE: Class inherits equals() and uses Object.hashCode() (HE_INHERITS_EQUALS_USE_HASHCODE)

This class inherits from an abstract superclass, and from (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 method to throw .

IC: Superclass uses subclass during initialization (IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION)

During the initialization of a class, the class makes an active use of a subclass. That subclass will not yet be initialized at the time of this use. For example, in the following code, will be null.

public class CircularClassInitialization { static class InnerClassSingleton extends CircularClassInitialization { static InnerClassSingleton singleton = new InnerClassSingleton(); } static CircularClassInitialization foo = InnerClassSingleton.singleton; }

IMSE: Dubious catching of IllegalMonitorStateException (IMSE_DONT_CATCH_IMSE)

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).

ISC: Needless instantiation of class that only supplies static methods (ISC_INSTANTIATE_STATIC_CLASS)

This class allocates an object that is based on a class that only supplies static methods. This object does not need to be created, just access the static methods directly using the class name as a qualifier.

It: Iterator next() method can't throw NoSuchElementException (IT_NO_SUCH_ELEMENT)

This class implements the interface.  However, its method is not capable of throwing .  The method should be changed so it throws if is called when there are no more elements to return.

J2EE: Store of non serializable object into HttpSession (J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION)

This code seems to be storing a non-serializable object into an HttpSession. If this session is passivated or migrated, an error will result.

JCIP: Fields of immutable classes should be final (JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS)

The class is annotated with net.jcip.annotations.Immutable or javax.annotation.concurrent.Immutable, and the rules for those annotations require that all fields are final. .

ME: Public enum method unconditionally sets its field (ME_ENUM_FIELD_SETTER)

This public method declared in public enum unconditionally sets enum field, thus this field can be changed by malicious code or by accident from another package. Though mutable enum fields may be used for lazy initialization, it's a bad practice to expose them to the outer world. Consider removing this method or declaring it package-private.

ME: Enum field is public and mutable (ME_MUTABLE_ENUM_FIELD)

A mutable public field is defined inside a public enum, thus can be changed by malicious code or by accident from another package. Though mutable enum fields may be used for lazy initialization, it's a bad practice to expose them to the outer world. Consider declaring this field final and/or package-private.

NP: Method with Boolean return type returns explicit null (NP_BOOLEAN_RETURN_NULL)

A method that returns either Boolean.TRUE, Boolean.FALSE or null is an accident waiting to happen. This method can be invoked as though it returned a value of type boolean, and the compiler will insert automatic unboxing of the Boolean value. If a null value is returned, this will result in a NullPointerException.

NP: Clone method may return null (NP_CLONE_COULD_RETURN_NULL)

This clone method seems to return null in some circumstances, but clone is never allowed to return a null value. If you are convinced this path is unreachable, throw an AssertionError instead.

NP: equals() method does not check for null argument (NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT)

This implementation of equals(Object) violates the contract defined by java.lang.Object.equals() because it does not check for null being passed as the argument. All equals() methods should return false if passed a null value.

NP: toString method may return null (NP_TOSTRING_COULD_RETURN_NULL)

This toString method seems to return null in some circumstances. A liberal reading of the spec could be interpreted as allowing this, but it is probably a bad idea and could cause other code to break. Return the empty string or some other appropriate string rather than null.

Nm: Class names should start with an upper case letter (NM_CLASS_NAMING_CONVENTION)

Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words-avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).

Nm: Class is not derived from an Exception, even though it is named as such (NM_CLASS_NOT_EXCEPTION)

This class is not derived from another exception, but ends with 'Exception'. This will be confusing to users of this class.

Nm: Confusing method names (NM_CONFUSING)

The referenced methods have names that differ only by capitalization.

Nm: Field names should start with a lower case letter (NM_FIELD_NAMING_CONVENTION)

Names of fields that are not final should be in mixed case with a lowercase first letter and the first letters of subsequent words capitalized.

Nm: Use of identifier that is a keyword in later versions of Java (NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER)

The identifier is a word that is reserved as a keyword in later versions of Java, and your code will need to be changed in order to compile it in later versions of Java.

Nm: Use of identifier that is a keyword in later versions of Java (NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER)

This identifier is used as a keyword in later versions of Java. This code, and any code that references this API, will need to be changed in order to compile it in later versions of Java.

Nm: Method names should start with a lower case letter (NM_METHOD_NAMING_CONVENTION)

Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

Nm: Class names shouldn't shadow simple name of implemented interface (NM_SAME_SIMPLE_NAME_AS_INTERFACE)

This class/interface has a simple name that is identical to that of an implemented/extended interface, except that the interface is in a different package (e.g., extends ). This can be exceptionally confusing, create lots of situations in which you have to look at import statements to resolve references and creates many opportunities to accidentally define methods that do not override methods in their superclasses.

Nm: Class names shouldn't shadow simple name of superclass (NM_SAME_SIMPLE_NAME_AS_SUPERCLASS)

This class has a simple name that is identical to that of its superclass, except that its superclass is in a different package (e.g., extends ). This can be exceptionally confusing, create lots of situations in which you have to look at import statements to resolve references and creates many opportunities to accidentally define methods that do not override methods in their superclasses.

Nm: Very confusing method names (but perhaps intentional) (NM_VERY_CONFUSING_INTENTIONAL)

The referenced methods have names that differ only by capitalization. This is very confusing because if the capitalization were identical then one of the methods would override the other. From the existence of other methods, it seems that the existence of both of these methods is intentional, but is sure is confusing. You should try hard to eliminate one of them, unless you are forced to have both due to frozen APIs.

Nm: Method doesn't override method in superclass due to wrong package for parameter (NM_WRONG_PACKAGE_INTENTIONAL)

The method in the subclass doesn't override a similar method in a superclass because the type of a parameter doesn't exactly match the type of the corresponding parameter in the superclass. For example, if you have:

import alpha.Foo; public class A { public int f(Foo x) { return 17; } } ---- import beta.Foo; public class B extends A { public int f(Foo x) { return 42; } public int f(alpha.Foo x) { return 27; } }

The method defined in class doesn't override the method defined in class , because the argument types are 's from different packages.

In this case, the subclass does define a method with a signature identical to the method in the superclass, so this is presumably understood. However, such methods are exceptionally confusing. You should strongly consider removing or deprecating the method with the similar but not identical signature.

ODR: Method may fail to close database resource (ODR_OPEN_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 (ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH)

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 (OS_OPEN_STREAM)

The method creates an IO stream object, does not assign it to any fields, pass it to other methods that might close it, 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 block to ensure that streams are closed.

OS: Method may fail to close stream on exception (OS_OPEN_STREAM_EXCEPTION_PATH)

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 block to ensure that streams are closed.

PZ: Don't reuse entry objects in iterators (PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS)

The entrySet() method is allowed to return a view of the underlying Map in which an Iterator and Map.Entry. This clever idea was used in several Map implementations, but introduces the possibility of nasty coding mistakes. If a map returns such an iterator for an entrySet, then will go badly wrong. All of the Map implementations in OpenJDK 1.7 have been rewritten to avoid this, you should to.

RC: Suspicious reference comparison to constant (RC_REF_COMPARISON_BAD_PRACTICE)

This method compares a reference value to a constant using the == or != operator, where the correct way to compare instances of this type is generally with the equals() method. It is possible to create distinct instances that are equal but do not compare as == since they are different objects. Examples of classes which should generally not be compared by reference are java.lang.Integer, java.lang.Float, etc.

RC: Suspicious reference comparison of Boolean values (RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN)

This method compares two Boolean values using the == or != operator. Normally, there are only two Boolean values (Boolean.TRUE and Boolean.FALSE), but it is possible to create other Boolean objects using the constructor. It is best to avoid such objects, but if they do exist, then checking Boolean objects for equality using == or != will give results than are different than you would get using

RR: Method ignores results of InputStream.read() (RR_NOT_CHECKED)

This method ignores the return value of one of the variants of

2017-10-27: rewrite

This description is outside the conventional definition of a null pointer error, but it can produce a null pointer nonetheless, though more often producing other errors, or none at all. It often gives no indication of its existence other than 'if or when' the program fails to perform as expected. This provides non-conventional examples and definitions of potential sources of null pointer assignment errors, rather than defining conventional understanding which is more an error in convention than an error in programming logic.

This type of error (undefined, or null) is much rarer. But modern programming, using benchtop devices like an Arduino, Raspberry PI, AMD, or any other computer on a chip programming exists in a myriad of forms, many of which are as simple today as yesteryear, this problem still exists today and can occur even in the most sophisticated of systems. Additionally, companies that build their own variable or data structures are probably also the most likely people to see this nowadays. The intention is to show examples that can aid in recognition.

For this to be a 'null' pointer error, the value assigned just has to be '0' or 'null'. But it has historically been called a 'null pointer error' not just being a simple null pointer; but because of their occurrence when clearing or zeroing out an array, the routine doing so overshoots or undershoots the boundaries of the array. However, simply it's an error created by array boundary miscalculations that can produce null pointer assignments and other errors. These are often not easily detected and may not generate an error immediately or at all, because the address that the pointer originally pointed to when defined has been overwritten and now contains an undesirable value (a bad address). And when, and by what it was overwritten can be almost impossible to find. This is included as part of the definition of types of error which produce null pointers. Where the pointer will be overwritten with a null, or zero and it will generate an error, and one is left with the problem of finding what modified it. Extra care must be taken to ensure that indexes are calculated properly with the appropriate consideration to base option 0 or 1. And also calculating correctly when moving data blocks. Fortunately many sophisticated development software applications and high level languages can catch a lot of these issues before or during compiling, when the variable array type is explicitly cast, or when the program can be written in a runtime environment and monitors array boundaries.

A null pointer is, as was defined in older days, any variable which gets used as a pointer and the address contents of the pointer's address, meaning the address the pointer points to, not the location it points to, is zero or null, OR has been modified, overwritten without the programmer's intent or knowledge, which could be a null, but could be any other value. Often only the null pointer creates an error message, even though the code may create an error, as it's often blocks of data containing nulls that's written to wrong locations. Instead of pointing to the original defined address where the data should reside, it now contains a null or unknown address moving data to an invalid or unwanted location overwriting and corrupting the code or data there. Because the failure caused to the data, or code may not immediately execute, or get used as it's moved to an existing unused memory location, when the code or data does cause a problem at a later time in the run, there can be no information on the 'real' location of the error, whether it creates or assigns null pointers or other corruption, it modifies code, and things can get weird, really weird.

To summarize, a null pointer is any null address used to point to a memory location regardless of what creates it. A null pointer assignment error, or many other errors, can be assigned to this issue and example.

In simpler architecture or programming environments, It can refer to any code which unintentionally ends up creating nulls as pointers, or creates a bug that in anyway halts the execution, like overwriting a byte in the return stack, overwriting code, putting code or data in the wrong location, not just as an address. So, while the examples above, work fine to define an example of a null pointer. So we expand the concept, A null pointer is any pointer which gets used as a variable pointer, and the address location of that variable for any one of multiple reasons now contains a 'null' or any unintended value that points to an undesirable memory location no matter how it got there.

So, finally, one can get a null pointer error, and upon examining the pointer finds it contains a null; but, cannot find the code that placed the null into the pointer or assigned it. This is a broad definition of null pointer assignment error, and is the worst case scenario of a null pointer error. When this occurs in a large program, this can be the death of the program because if the error existed previously, and was writing to the wrong memory location, and that location had yet to be allocated, the error goes unnoticed until the program gets expanded, and now the wrong memory location may exist inside of the new code, generating random errors. For example: the bad address value causes data to be written outside of the variable space defined, but goes unnoticed for some time because it's being written, and it being read, and everything 'appears' OK! But, the program expands, gets larger, new code exists in the same address space as the memory where the original old bug existed which writes data to the wrong address space and no one noticed, whether one byte, or a whole block of data! But, now, there's new code there. And it's gets corrupted by the old undiscovered bug, and to find the error which existed a year earlier is now almost, if not totally, impossible to find. Administrator logic usually dictates, why look there, it ran and worked just fine last year. But, now, nothing works, major pieces are broken, look and look and nothing do you find. It's as if the error doesn't exist, and yet it does. What's causing it, who suspects code written years earlier? Null pointers and many other errors are caused by this too.

Perhaps this answer is misplaced and would serve better to be listed elsewhere. Moderator? Perhaps, there is concern because this 'answer' is not considered pertinent because there is some concern over the use of the word "assignment" in the question, meaning intentionally assigned. However, the concept of assignment does not require knowledge or consent. An algorithm or code can assign values. Null pointers can be created many ways, the example here is probably the most common one outside of conventional errors.

It appears this information has 'a' place, and is included here as an answer. Positive fruitful feedback or suggestions are appreciated, rather than a simple down vote, if anyone cares to comment, perhaps a meta discussion is in order?

Cheers.

0 Thoughts to “Divide Error Null Pointer Assignment Java

Leave a comment

L'indirizzo email non verrĂ  pubblicato. I campi obbligatori sono contrassegnati *