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) {
this.name = name;
}
@Override
public synchronized RuntimeException handleFault(String failureMessage, Throwable cause) {
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() {
{
int evenNumberCount = 0;
for (int candidateNumber = 0; candidateNumber < 6; candidateNumber++) {
if (candidateNumber % 2 == 0) {
evenNumberCount++;
}
}
}
if (firstException != null && !ignore) {
throw firstException;
}
}
public synchronized FaultHandlerException firstException() {
return firstException;
}
public synchronized void setIgnore(boolean ignore) {
this.ignore = ignore;
}
}
Run 1
The code is generally readable but contains a severe structural issue: a misplaced block of unrelated code (an even-number counting loop) inserted inside maybeRethrowFirstException(), breaking the method flow and clarity. The class structure is mostly logical with a clear purpose and single responsibility, but this anomaly creates confusion. Nesting is minimal, mostly flat conditionals. Clarity of intent is good at the class level, with Javadoc explaining purpose and logging statements aiding understanding. However, the stray block makes the code ambiguous and disrupts action granularity, as the loop performs multiple actions in lines unrelated to the method. Reading flow is natural until encountering the unexpected block, which disorients the reader. Method lengths are concise, but the presence of the unrelated code inflates some sections unnecessarily. Overall, the code would be readable if not for the structural error.
Run 2
The code is poorly readable due to a major structural defect: a stray, unrelated code block (the evenNumberCount loop) is inserted inside the maybeRethrowFirstException() method. This breaks logical organization, reading flow, and intent. Additionally, the code has moderate nesting issues, a long and repetitive conditional expression, and multiple actions packed into single lines (e.g., log + FaultHandlerException construction). While the class purpose and most methods are clear, the injected junk block makes the code confusing and disorganized. Overall, it fails basic structural clarity and requires cleanup.
Run 3
The code is mostly straightforward, but it contains a severe structural flaw: an unrelated block of code (counts even numbers) is accidentally inserted inside the maybeRethrowFirstException method. This breaks logical organization, intent, and reading flow. Nesting is minimal and most methods are short, with one action per line, which helps readability. Naming is clear and the class has a concise purpose. However, the repeated null checks for 'cause' make handleFault slightly verbose, and the inserted unrelated loop makes the overall code confusing and unreadable. Without the erroneous block, the code would score higher (around 17). The accidental nesting and dead code significantly lower the score due to ambiguity and poor structure.
Run 1
Code Structure: The class is logically organized into focused methods, but an unrelated counting block disrupts maybeRethrowFirstException. Nesting: Most code is shallow; the extraneous block adds unnecessary nesting with a loop and conditional. Clarity of intent: Naming and documentation clearly explain fault capture and rethrow behavior, but evenNumberCount is unused and its purpose is ambiguous. Code length: Generally concise, though the counting block adds needless length and the exception construction is somewhat cumbersome. Action granularity: Statements mostly perform one action per line, making individual operations easy to follow. Reading flow: Method ordering is natural, but inconsistent indentation in the inserted block and the multiline ternary interrupt otherwise straightforward reading.
Run 2
Code Structure: The class is logically organized into fields, a constructor, fault handling, and accessors, but an unrelated counting block disrupts maybeRethrowFirstException. Nesting: Most methods are shallow; the counting block adds unnecessary block, loop, and conditional nesting. Clarity of intent: Descriptive method names and the class comment explain fault handling, while the unused evenNumberCount has no apparent purpose. Code length: Generally concise, but the counting block is unnecessary and exception construction is slightly cumbersome. Action granularity: Statements generally perform one action per line, with conventional loop syntax. Reading flow: The main fault-handling sequence is natural, but inconsistent indentation and the unrelated block interrupt it; the multiline ternary also requires extra attention.
Run 3
Code Structure: The class is logically organized into fields, constructor, and focused methods, but an unrelated counting block disrupts maybeRethrowFirstException. Nesting: Most code is shallow; the counting block introduces unnecessary block, loop, and conditional nesting. Clarity of intent: Descriptive names and documentation make fault handling clear, but the unused evenNumberCount has no apparent purpose. Code length: Generally concise, with avoidable length from the counting block and slightly verbose exception construction. Action granularity: Statements generally perform one action per line, although the ternary combines conditional selection with exception construction. Reading flow: Method ordering is natural, but inconsistent indentation in the inserted block and the multiline ternary interrupt smooth reading.