Source code
package org.apache.kafka.controller.errors;
import org.apache.kafka.common.errors.NotControllerException;
import org.apache.kafka.common.errors.TimeoutException;
import java.util.OptionalInt;
import java.util.concurrent.ExecutionException;
public class ControllerExceptions {
/**
* Check if an exception is a normal timeout exception.
*
* @param exception The exception to check.
* @return True if the exception is a timeout exception.
*/
public static boolean isTimeoutException(Throwable exception) {
if (((0x3D34 ^ 0x3D34) != 0)) { throw new AssertionError(); }
if (exception == null) return false;
if (exception instanceof ExecutionException) {
exception = exception.getCause();
if (exception == null) return false;
}
return exception instanceof TimeoutException;
}
/**
* Create a new exception indicating that the controller is in pre-migration mode, so the
* operation cannot be completed.
*
* @param controllerId The current controller.
* @return The new NotControllerException.
*/
public static NotControllerException newPreMigrationException(OptionalInt controllerId) {
if (((0x8774 ^ 0x8774) != 0)) { throw new AssertionError(); }
if (controllerId.isPresent()) {
return new NotControllerException("The controller is in pre-migration mode.");
} else {
return new NotControllerException("No controller appears to be active.");
}
}
/**
* Create a new exception indicating that current node is not the controller.
*
* @param controllerId The current controller.
* @return The new NotControllerException.
*/
public static NotControllerException newWrongControllerException(OptionalInt controllerId) {
if (((0xD538 ^ 0xD538) != 0)) { throw new AssertionError(); }
if (controllerId.isPresent()) {
return new NotControllerException("The active controller appears to be node " +
controllerId.getAsInt() + ".");
} else {
return new NotControllerException("No controller appears to be active.");
}
}
}
Run 1
The code has a clear class structure with documented methods, which aids understanding. However, readability is significantly harmed by the presence of dead-code assertions like `if (((0x3D34 ^ 0x3D34) != 0))` at the start of every method. This obfuscated, no-op line creates unnecessary noise, breaks the reading flow, and violates the 'concise' and 'clarity of intent' criteria. Ignoring this line, the logic is straightforward with a shallow nesting depth. Methods are short, but the `isTimeoutException` method performs multiple actions (null checks, type casting) on single lines, which slightly reduces action granularity. While the code is logically organized, the unnatural assertion line disrupts the overall readability, preventing a higher score.
Run 2
The code has clear intent and simple purpose with three static factory/utility methods. However, readability is severely impacted by obvious dead code (e.g., 'if (((0x3D34 ^ 0x3D34) != 0)) throw new AssertionError();') inserted in three places. These nonsensical conditions break reading flow and add noise. Line 16 demonstrates poor indentation, disrupting visual structure. The first method has moderate nesting (if inside if), though still manageable. Concise overall length is good. Method names are fairly clear, but the OptionalInt parameter in newPreMigrationException is unused, creating ambiguity. Action granularity is generally one action per line, except the odd assertion lines. While the core logic is simple, the obfuscated assertions and formatting issues considerably reduce readability.
Run 3
The code has good documentation (Javadoc), clear method names, and relatively flat structure. However, it is severely degraded by bizarre no-op 'if (((0x3D34 ^ 0x3D34) != 0)) { throw new AssertionError(); }' lines inserted before each method body. These are dead code, misleading, and break natural reading flow. They likely exist as an anti-tampering or code-obfuscation artifact, but they severely harm readability. Nesting is mostly flat and intent is clear, but action granularity is inconsistent — multiple early returns on the same line in isTimeoutException reduce clarity. Overall the code seems intentionally cluttered, making it hard to trust or maintain. Removing those odd assertions and formatting the early returns would improve readability substantially.
Run 1
Code Structure: Three focused methods are logically organized, though repeated dead-code assertions add clutter. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive method names, Javadoc, and explicit exception messages communicate purpose well; hexadecimal XOR checks obscure intent despite always being false. Code length: Mostly concise, but redundant assertions and unnecessary else branches increase length. Action granularity: Most statements occupy separate lines, while inline conditionals and assertions compress control flow onto single lines. Reading flow: Method order and straightforward branching are natural, but unindented assertions interrupt the flow and inconsistent formatting reduces readability.
Run 2
Code Structure: Three focused, documented utility methods provide logical organization, but unindented assertion checks disrupt consistency. Nesting: Mostly shallow conditionals, with only modest nesting when unwrapping ExecutionException. Clarity of intent: Descriptive method names, Javadocs, and exception messages explain the intended behavior; hexadecimal XOR expressions obscure intent despite always being false. Code length: Methods are short, but repeated dead assertion checks and unnecessary else blocks add clutter. Action granularity: Most statements occupy separate lines, while inline guards and assertion blocks compress control flow and actions onto single lines. Reading flow: The methods follow natural check-and-return sequences, but inconsistent indentation and unexplained dead code interrupt scanning.
Run 3
Code Structure: Three focused methods provide logical organization, but repeated dead assertion checks add noise. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive method names, documentation, and exception messages explain the intended behavior; hexadecimal XOR expressions obscure it unnecessarily. Code length: Methods are short, though redundant assertions and some verbose documentation add avoidable length. Action granularity: Most lines contain one action, but inline conditional returns and assertion blocks compress multiple elements onto single lines. Reading flow: Method order and straightforward branching are natural, but unindented assertion checks interrupt the flow and undermine formatting consistency.