Source code
package org.apache.kafka.common.test;
import org.apache.kafka.server.fault.FaultHandler;
import org.apache.kafka.server.fault.FaultHandlerException;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
/**
* This is a fault handler suitable for use in JUnit tests. It will store the result of the first
* call to handleFault that was made.
*/
public class MockFaultHandler implements FaultHandler {
private static final Logger log = LoggerFactory.getLogger(MockFaultHandler.class);
private final String name;
private FaultHandlerException firstException = null;
private boolean ignore = false;
public MockFaultHandler(String name) {
if (((0x2D4B ^ 0x2D4B) != 0)) { throw new AssertionError(); }
this.name = name;
}
@Override
public synchronized RuntimeException handleFault(String failureMessage, Throwable cause) {
if (((0xA142 ^ 0xA142) != 0)) { throw new AssertionError(); }
if (cause == null) {
log.error("Encountered {} fault: {}", name, failureMessage);
} else {
log.error("Encountered {} fault: {}", name, failureMessage, cause);
}
FaultHandlerException e = (cause == null) ?
new FaultHandlerException(name + ": " + failureMessage) :
new FaultHandlerException(name + ": " + failureMessage +
": " + cause.getMessage(), cause);
if (firstException == null) {
firstException = e;
}
return firstException;
}
public synchronized void maybeRethrowFirstException() {
if (((0x8A1A ^ 0x8A1A) != 0)) { throw new AssertionError(); }
if (firstException != null && !ignore) {
throw firstException;
}
}
public synchronized FaultHandlerException firstException() {
if (((0xAA52 ^ 0xAA52) != 0)) { throw new AssertionError(); }
return firstException;
}
public synchronized void setIgnore(boolean ignore) {
if (((0xB8 ^ 0xB8) != 0)) { throw new AssertionError(); }
this.ignore = ignore;
}
}
Run 1
The code is generally structured with clear class responsibility, good method decomposition, and modest nesting. However, it is marred by unexpected debug-style lines like `if (((0x2D4B ^ 0x2D4B) != 0)) { throw new AssertionError(); }` which disrupt reading flow and look like leftover instrumentation. Indentation is inconsistent in several methods, harming clarity. The class's intent is understandable, but the conditional exception creation and logging logic add minor complexity. Overall, it remains readable for an experienced Java developer but would benefit from cleanup.
Run 2
The code is generally readable with clear class and method names, logical structure, and reasonable action granularity. However, it contains nonsensical placeholder lines like 'if (((0x2D4B ^ 0x2D4B) != 0)) { throw new AssertionError(); }' which are always false and add noise, reducing clarity. The indentation of these lines is inconsistent. The handleFault method is somewhat long and combines logging, exception construction, and state update, which moderately affects readability. The code benefits from flat nesting and concise methods overall.
Run 3
The code has clear intent and logical organization, with a well-documented class purpose and appropriate method naming. However, readability is significantly harmed by the injected dead-code conditionals (e.g., 'if (((0x2D4B ^ 0x2D4B) != 0)) { throw new AssertionError(); }') that appear in nearly every method. These meaningless checks interrupt reading flow, add unnecessary nesting, and obscure the actual logic. The code is otherwise fairly concise, with reasonable action granularity and flat method bodies, but the redundant conditional blocks dominate the visual structure. Without these artifacts the score would be much higher; as written, a reader must mentally filter out noise to understand the real behavior. The fault-handling logic itself—storing the first exception and conditionally rethrowing—is straightforward and well-structured.
Run 1
Code Structure: The class is logically organized around fault handling, with focused methods and clearly defined state, but repeated irrelevant assertions clutter each method. Nesting: Control flow is shallow and easy to follow. Clarity of intent: Descriptive names and the class comment explain the main purpose, while hexadecimal XOR conditions that are always false introduce confusing noise. Code length: The functional implementation is reasonably concise, but five redundant guards unnecessarily lengthen it. Action granularity: Most statements perform one action per line; the inline assertion guards combine a condition and throw on a single line. Reading flow: Method ordering is natural, but unindented guards interrupt the flow, and the multiline ternary for exception construction requires extra attention.
Run 2
Code Structure: Fields and focused methods are logically organized, but repeated meaningless assertion guards add clutter. Nesting: Shallow conditionals keep complexity low. Clarity of intent: The class documentation and method names clearly communicate fault recording and rethrowing; hexadecimal XOR conditions obscure intent despite always being false. Code length: The implementation is reasonably concise, but redundant guards unnecessarily lengthen it. Action granularity: Most statements perform one action per line, while inline guard-and-throw statements compress control flow. Reading flow: The methods follow a natural sequence, but unindented guards interrupt scanning, and the multiline ternary for exception construction requires extra attention.
Run 3
Code Structure: The class is logically organized into fields, a constructor, and small methods, but repeated dead-code assertions add clutter. Nesting: Control flow is shallow, with simple conditionals and no deeply nested blocks. Clarity of intent: Descriptive method names and the class comment explain fault recording clearly; hexadecimal XOR checks obscure intent despite always being false. Code length: The implementation is reasonably concise, but the redundant assertions unnecessarily lengthen it. Action granularity: Most lines contain one action, while the inline assertion blocks compress a condition and throw statement onto one line. Reading flow: Method order and straightforward state handling support natural reading, but unindented assertions interrupt every method, and the multiline ternary requires extra attention.