EnterpriseQualityCoding/FizzBuzzEnterpriseEdition · warning · UnsupportedOperationException

The integers could not be compared.

Error message

The integers could not be compared.

What it means

ThreeWayIntegerComparator.Compare orders two ints through an exhaustive if/else chain: equal, less-than, greater-than — and the final else throws UnsupportedOperationException with 'The integers could not be compared'. For the primitive type int those three branches are mathematically exhaustive, so the throw is dead defensive code (a total order always exists for ints). It can never fire with valid Java semantics; its presence is part of the codebase's satirical over-engineering.

Source

Thrown at src/main/java/com/seriouscompany/business/java/fizzbuzz/packagenamingpackage/impl/strategies/comparators/integercomparator/ThreeWayIntegerComparator.java:29

public final class ThreeWayIntegerComparator {

	private ThreeWayIntegerComparator() {}

	/**
	 * @param nFirstInteger int
	 * @param nSecondInteger int
	 * @return ThreeWayIntegerComparisonResult
	 */
	public static ThreeWayIntegerComparisonResult Compare(final int nFirstInteger, final int nSecondInteger) {
		if (nFirstInteger == nSecondInteger) {
			return ThreeWayIntegerComparisonResult.FirstEqualsSecond;
		} else if (nFirstInteger < nSecondInteger) {
			return ThreeWayIntegerComparisonResult.FirstIsLessThanSecond;
		} else if (nFirstInteger > nSecondInteger) {
			return ThreeWayIntegerComparisonResult.FirstIsGreaterThanSecond;
		} else {
			// If the integers cannot be compared, then something is seriously wrong with the numbers.
			throw new UnsupportedOperationException(Constants.THE_INTEGERS_COULD_NOT_BE_COMPARED);
		}
	}

}

View on GitHub (pinned to 4922c077c0)

Solutions

1. Recognize it is unreachable for ints — no action is needed for correct inputs; do not add defensive handling around it.
2. If porting this comparator to double/float, handle NaN before the chain: if (Double.isNaN(a) || Double.isNaN(b)) throw new IllegalArgumentException(...).
3. If a code change introduced fall-through, restore the exhaustive == / < / > chain exactly so the else remains dead.
4. For test coverage of the branch, delete the else or extract it with a comment marking it unreachable — keeping it only aids the satire.

Example fix

// before (NaN port makes the throw reachable)
public static ThreeWayIntegerComparisonResult Compare(double a, double b) {
    if (a == b) return FirstEqualsSecond;
    else if (a < b) return FirstIsLessThanSecond;
    else if (a > b) return FirstIsGreaterThanSecond;
    else throw new UnsupportedOperationException("The integers could not be compared.");
}

// after (validate NaN up front, keep total order)
public static ThreeWayIntegerComparisonResult Compare(double a, double b) {
    if (Double.isNaN(a) || Double.isNaN(b)) {
        throw new IllegalArgumentException("NaN is not comparable");
    }
    if (a < b) return FirstIsLessThanSecond;
    if (a > b) return FirstIsGreaterThanSecond;
    return FirstEqualsSecond;
}

// For int: nothing to validate — the branch is unreachable.
// If porting to double/float, validate before Compare:
if (Double.isNaN(a) || Double.isNaN(b)) {
    throw new IllegalArgumentException("NaN inputs are not comparable");
}
final ThreeWayIntegerComparisonResult r = ThreeWayIntegerComparator.Compare(a, b);

// Narrow numeric inputs to totally-ordered values before comparing
static boolean isTotallyOrdered(final double v) {
    return !Double.isNaN(v) && !Double.isInfinite(v);
}

if (isTotallyOrdered(a) && isTotallyOrdered(b)) {
    // safe: all of ==, <, > will decide
}

// Normally unnecessary; only around modified/ported comparators
try {
    final ThreeWayIntegerComparisonResult r = ThreeWayIntegerComparator.Compare(x, y);
} catch (final UnsupportedOperationException e) {
    if (!"The integers could not be compared.".equals(e.getMessage())) throw e;
    throw new IllegalStateException("Comparator contract violated — non-int inputs or modified chain", e);
}

When it happens

Trigger: Effectively unreachable: Compare(int, int) always returns from the first three branches for any int pair, including MIN_VALUE/MAX_VALUE. It would only be observable if the code were ported to non-primitive numeric types lacking a total order (e.g. float/double NaN, where none of ==, <, > holds), or if the comparison chain were modified to introduce a gap between the conditions.

Common situations: Developers see the string in logs or test-coverage reports and assume a real defect; or the pattern is copy-pasted to Double.compare-style logic where NaN genuinely fails all three comparisons and the throw becomes live. Also hit when someone 'simplifies' one of the chained conditions (e.g. changing < to <= incorrectly), making some inputs fall through to the else.

Related errors

• An attempt was made to divide by zero.
• com.seriouscompany.business.java.fizzbuzz.packagenamingpacka

AI-assisted analysis of EnterpriseQualityCoding/FizzBuzzEnterpriseEdition@4922c077c0 (2026-08-14). Data as JSON: /api/errors/89013c6cd3a2c091. Report an issue: GitHub.