<?xml version="1.0" encoding="UTF-8"?>

<ruleset name="Error Prone"

xmlns="http://pmd.sourceforge.net/ruleset/2.0.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://pmd.sourceforge.net/ruleset/2.0.0 https://pmd.sourceforge.io/ruleset_2_0_0.xsd">

<description>

Rules to detect constructs that are either broken, extremely confusing or prone to runtime errors.

</description>

<rule name="AssertEqualsArgumentOrder"

language="java"

since="7.26.0"

message="This assertEquals() call has mixed up expected and actual arguments"

class="net.sourceforge.pmd.lang.java.rule.errorprone.AssertEqualsArgumentOrderRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#assertequalsargumentorder">

<description>

Unit testing frameworks provide the `assertEquals` method that takes expected and actual

value of an object as arguments.

Passing a constant as the actual value and a computed value as the expected value

indicates that the actual and expected values were swapped, leading to confusing

error messages should the test fail.

This rule currently supports assertions from JUnit Jupiter, JUnit versions 4 and 3,

TestNG, Spring assertions and the JSONAssert library.

</description>

<priority>3</priority>

<example>

<![CDATA[

</example>

</rule>

<rule name="AssignmentInOperand"

language="java"

since="1.03"

message="Avoid assignment to {0} in operand"

class="net.sourceforge.pmd.lang.java.rule.errorprone.AssignmentInOperandRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#assignmentinoperand">

<description>

Avoid assignments in operands; this can make code more complicated and harder to read.

</description>

<priority>3</priority>

<example>

</example>

</rule>

<rule name="AssignmentToNonFinalStatic"

language="java"

since="2.2"

message="Possible unsafe assignment to non-final static field ''{0}'' in a constructor."

class="net.sourceforge.pmd.lang.java.rule.errorprone.AssignmentToNonFinalStaticRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#assignmenttononfinalstatic">

<description>

Identifies a possible unsafe usage of a static field.

</description>

<priority>3</priority>

<example>

</example>

</rule>

<rule name="AvoidAccessibilityAlteration"

language="java"

since="4.1"

message="You should not modify visibility of constructors, methods or fields using setAccessible()"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidaccessibilityalteration">

<description>

Methods such as `getDeclaredConstructors()`, `getDeclaredMethods()`, and `getDeclaredFields()` also

return private constructors, methods and fields. These can be made accessible by calling `setAccessible(true)`.

This gives access to normally protected data which violates the principle of encapsulation.

This rule detects calls to `setAccessible` and finds possible accessibility alterations.

If the call to `setAccessible` is wrapped within a `PrivilegedAction`, then the access alteration

is assumed to be deliberate and is not reported.

Note that with Java 17 the Security Manager, which is used for `PrivilegedAction` execution,

is deprecated: [JEP 411: Deprecate the Security Manager for Removal](https://openjdk.org/jeps/411).

For future-proof code, deliberate access alteration should be suppressed using the usual

suppression methods (e.g. by using `@SuppressWarnings` annotation).

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidAssertAsIdentifier"

language="java"

maximumLanguageVersion="1.3"

since="3.4"

message="Avoid using assert as an identifier; it became a reserved word in JDK 1.4"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidassertasidentifier">

<description>

Use of the term `assert` will conflict with newer versions of Java since it is a reserved word.

Since Java 1.4, the token `assert` became a reserved word and using it as an identifier will

result in a compilation failure for Java 1.4 and later. This rule is therefore only useful

for old Java code before Java 1.4. It can be used to identify problematic code prior to a Java update.

</description>

<priority>2</priority>

<properties>

<property name="xpath">

<value>//VariableId[@Name='assert']</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidBranchingStatementAsLastInLoop"

language="java"

since="5.0"

class="net.sourceforge.pmd.lang.java.rule.errorprone.AvoidBranchingStatementAsLastInLoopRule"

message="Avoid using a branching statement as the last in a loop."

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidbranchingstatementaslastinloop">

<description>

Using a branching statement as the last part of a loop may be a bug, and/or is confusing.

Ensure that the usage is not a bug, or consider using another approach.

</description>

<priority>2</priority>

<example>

</example>

</rule>

<rule name="AvoidCallingFinalize"

language="java"

since="3.0"

message="Avoid calling finalize() explicitly"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidcallingfinalize">

<description>

The method Object.finalize() is called by the garbage collector on an object when garbage collection determines

that there are no more references to the object. It should not be invoked by application logic.

Note that Oracle has declared Object.finalize() as deprecated since JDK 9.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidCatchingGenericException"

since="4.2.6"

language="java"

message="Avoid catching {0} in try-catch block"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidcatchinggenericexception">

<description>

Avoid catching generic exceptions in try-catch blocks. Catching overly broad exception types makes it difficult

to understand what can actually go wrong in your code and can hide real problems.

**Why these exceptions should not be caught:**

* **Exception**: This is the base class for all checked exceptions. Catching it means you're handling all possible

checked exceptions the same way, which is rarely appropriate and makes error handling less precise.

* **RuntimeException**: These represent programming errors (like logic bugs) that should typically be fixed in

code rather than caught and handled. Catching them can hide bugs that should be addressed during development.

* **NullPointerException**: This usually indicates a programming error (accessing null references). Rather than

catching it, code should be written to avoid null pointer dereferences through null checks or defensive programming.

* **Throwable**: This is the superclass of all errors and exceptions. Catching it means you're trying to handle

both recoverable exceptions and serious errors (like OutOfMemoryError) the same way, which is dangerous.

* **Error**: These represent serious problems that applications should not try to handle (like OutOfMemoryError,

StackOverflowError). Catching Error can prevent the JVM from properly terminating when it encounters unrecoverable situations.

**Better approaches:**

- Catch specific exception types that you can meaningfully handle

- Use multiple catch blocks for different exception types that require different handling

- Consider using defensive programming techniques to prevent exceptions rather than catching them

</description>

<priority>3</priority>

<properties>

<property

name="typesThatShouldNotBeCaught"

type="List[String]"

description="List of canonical type names that should trigger a violation if used in a catch clause."

>

<value>

java.lang.NullPointerException,

java.lang.Exception,

java.lang.RuntimeException,

java.lang.Throwable,

java.lang.Error

</value>

</property>

<property name="xpath">

<value>

<![CDATA[

</value>

</property>

</properties>

<example>

<![CDATA[

</example>

</rule>

<rule name="AvoidCatchingNPE"

language="java"

since="1.8"

deprecated="true"

message="Avoid catching NullPointerException; consider removing the cause of the NPE."

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidcatchingnpe">

<description>

Code should never throw NullPointerExceptions under normal circumstances. A catch block may hide the

original error, causing other, more subtle problems later on.

**Deprecated:** This rule is deprecated since PMD 7.18.0 and will be removed with PMD 8.0.0.

This rule has been subsumed by {% rule AvoidCatchingGenericException %},

which is now configurable as to which exceptions cause a violation.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidCatchingThrowable"

language="java"

since="1.2"

deprecated="true"

message="A catch statement should never catch throwable since it includes errors."

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidcatchingthrowable">

<description>

Catching Throwable errors is not recommended since its scope is very broad. It includes runtime issues such as

OutOfMemoryError that should be exposed and managed separately.

**Deprecated:** This rule is deprecated since PMD 7.18.0 and will be removed with PMD 8.0.0.

This rule has been subsumed by {% rule AvoidCatchingGenericException %},

which is now configurable as to which exceptions cause a violation.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value><![CDATA[

]]></value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidDecimalLiteralsInBigDecimalConstructor"

language="java"

since="3.4"

message="Avoid creating BigDecimal with a decimal (float/double) literal. Use a String literal"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoiddecimalliteralsinbigdecimalconstructor">

<description>

One might assume that the result of "new BigDecimal(0.1)" is exactly equal to 0.1, but it is actually

equal to .1000000000000000055511151231257827021181583404541015625.

This is because 0.1 cannot be represented exactly as a double (or as a binary fraction of any finite

length). Thus, the long value that is being passed in to the constructor is not exactly equal to 0.1,

appearances notwithstanding.

The (String) constructor, on the other hand, is perfectly predictable: 'new BigDecimal("0.1")' is

exactly equal to 0.1, as one would expect. Therefore, it is generally recommended that the

(String) constructor be used in preference to this one.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidDuplicateLiterals"

language="java"

since="1.0"

message="The String literal {0} appears {1} times in this file; the first occurrence is on line {2}"

class="net.sourceforge.pmd.lang.java.rule.errorprone.AvoidDuplicateLiteralsRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidduplicateliterals">

<description>

Code containing duplicate String literals can usually be improved by declaring the String as a constant field.

</description>

<priority>3</priority>

<example>

</example>

</rule>

<rule name="AvoidEnumAsIdentifier"

language="java"

maximumLanguageVersion="1.4"

since="3.4"

message="Avoid using enum as an identifier; it's a reserved word in JDK 1.5"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidenumasidentifier">

<description>

Use of the term `enum` will conflict with newer versions of Java since it is a reserved word.

Since Java 1.5, the token `enum` became a reserved word and using it as an identifier will

result in a compilation failure for Java 1.5 and later. This rule is therefore only useful

for old Java code before Java 1.5. It can be used to identify problematic code prior to a Java update.

</description>

<priority>2</priority>

<properties>

<property name="xpath">

<value>//VariableId[@Name='enum']</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidFieldNameMatchingMethodName"

language="java"

since="3.0"

message="Field {0} has the same name as a method"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidfieldnamematchingmethodname">

<description>

It can be confusing to have a field name with the same name as a method. While this is permitted,

having information (field) and actions (method) is not clear naming. Developers versed in

Smalltalk often prefer this approach as the methods denote accessor methods.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidFieldNameMatchingTypeName"

language="java"

since="3.0"

message="It is somewhat confusing to have a field name matching the declaring class name"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidfieldnamematchingtypename">

<description>

It is somewhat confusing to have a field name matching the declaring type name.

This probably means that type and/or field names should be chosen more carefully.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidInstanceofChecksInCatchClause"

language="java"

since="3.0"

message="An instanceof check is being performed on the caught exception. Create a separate catch clause for {0}."

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidinstanceofchecksincatchclause">

<description>

Each caught exception type should be handled in its own catch clause.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidLiteralsInIfCondition"

language="java"

since="4.2.6"

message="Avoid using literals such as {0} in if statements"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidliteralsinifcondition">

<description>

Avoid using hard-coded literals in conditional statements. By declaring them as static variables

or private members with descriptive names maintainability is enhanced. By default, the literals "-1" and "0" are ignored.

More exceptions can be defined with the property "ignoreMagicNumbers".

The rule doesn't consider deeper expressions by default, but this can be enabled via the property `ignoreExpressions`.

With this property set to false, if-conditions like `i == 1 + 5` are reported as well. Note that in that case,

the property ignoreMagicNumbers is not taken into account, if there are multiple literals involved in such an expression.

</description>

<priority>3</priority>

<properties>

<property name="ignoreMagicNumbers"

description="Comma-separated list of magic numbers, that should be ignored"

type="String" value="-1,0"/>

<property name="ignoreExpressions"

description="If true, only literals in simple if conditions are considered. Otherwise literals in expressions are checked, too."

type="Boolean" value="true"/>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidLosingExceptionInformation"

since="4.2.6"

language="java"

message="Avoid statements in a catch block that invoke accessors on the exception without using the information"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidlosingexceptioninformation"

deprecated="true">

<description>

Statements in a catch block that invoke accessors on the exception without using the information

only add to code size. Either remove the invocation, or use the return result.

**Deprecated:** This rule is deprecated since PMD 7.17.0 and will be removed with PMD 8.0.0.

This rule has been replaced by {% rule UselessPureMethodCall %}.

</description>

<priority>2</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidMultipleUnaryOperators"

language="java"

since="4.2"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

message="Using multiple unary operators may be a bug, and/or is confusing."

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidmultipleunaryoperators">

<description>

The use of multiple unary operators may be problematic, and/or confusing.

Ensure that the intended usage is not a bug, or consider simplifying the expression.

</description>

<priority>2</priority>

<properties>

<property name="xpath">

<value><![CDATA[

]]></value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="AvoidUsingOctalValues"

language="java"

since="3.9"

message="Avoid integer literals that start with zero (interpreted as octal), remove the leading 0 to get a decimal literal (or use explicit 0x, 0b prefixes)"

class="net.sourceforge.pmd.lang.java.rule.errorprone.AvoidUsingOctalValuesRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#avoidusingoctalvalues">

<description>

Integer literals that start with zero are interpreted as octal (base-8) values in Java, which can lead to

unexpected behavior and bugs. Most developers expect decimal (base-10) interpretation, making octal literals

a common source of confusion and errors. For example, 012 equals 10 in decimal, not 12 as might be expected.

This rule helps prevent such mistakes by flagging integer literals that could be misinterpreted as decimal values.

Use decimal literals without leading zeros, or use explicit prefixes like 0x for hexadecimal or 0b for binary values to make the intended base clear.

</description>

<priority>3</priority>

<example>

</example>

</rule>

<rule name="BrokenNullCheck"

language="java"

since="3.8"

message="This expression will throw a NullPointerException"

class="net.sourceforge.pmd.lang.java.rule.errorprone.BrokenNullCheckRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#brokennullcheck">

<description>

The null check is broken since it will throw a NullPointerException itself.

It is likely that you used || instead of &amp;&amp; or vice versa.

</description>

<priority>2</priority>

<example>

</example>

</rule>

<rule name="CallSuperFirst"

since="4.2.5"

language="java"

message="super should be called at the start of the method"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#callsuperfirst">

<description>

Super should be called at the start of the method

This rule is intended for Android development. Don't use for general purpose java development!

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="CallSuperLast"

since="4.2.5"

language="java"

message="super should be called at the end of the method"

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#callsuperlast">

<description>

Super should be called at the end of the method

This rule is intended for Android development. Don't use for general purpose java development!

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>

<rule name="CheckSkipResult"

language="java"

since="5.0"

deprecated="true"

message="Check the value returned by the skip() method of an InputStream to see if the requested number of bytes has been skipped."

class="net.sourceforge.pmd.lang.java.rule.errorprone.CheckSkipResultRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#checkskipresult">

<description>

The skip() method may skip a smaller number of bytes than requested. Check the returned value to find out if it was the case or not.

**Deprecated:** This rule is deprecated since PMD 7.27.0 and will be removed with PMD 8.0.0.

This rule has been replaced by {% rule UnusedReturnValue %}

</description>

<priority>3</priority>

<example>

</example>

</rule>

<rule name="ClassCastExceptionWithToArray"

language="java"

since="3.4"

message="This usage of the Collection.toArray() method will throw a ClassCastException."

class="net.sourceforge.pmd.lang.rule.xpath.XPathRule"

externalInfoUrl="${pmd.website.baseurl}/pmd_rules_java_errorprone.html#classcastexceptionwithtoarray">

<description>

When deriving an array of a specific class from your Collection, one should provide an array of

the same class as the parameter of the `toArray()` method. Doing otherwise will result

in a `ClassCastException`.

</description>

<priority>3</priority>

<properties>

<property name="xpath">

<value>

</value>

</property>

</properties>

<example>

</example>

</rule>