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() {
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 well-structured and readable. It has clear separation of concerns with logical method organization, flat nesting, and concise implementation. The class purpose is documented, method names clearly convey intent, and functionality is appropriately granular. Minor issues include slightly awkward conditional handling for null causes (could use a helper method or ternary for cleaner separation) and the ternary operator spanning multiple lines in handleFault reduces readability slightly. The maybeRethrowFirstException method shows clear intent, and synchronized methods maintain thread-safety, though this could be noted. Overall, the code follows good Java practices, maintains reasonable length, and flows naturally from top to bottom.
Run 2
The code is well-structured with clear class and method separation. It uses a single level of nesting in the handleFault method, maintaining flat logic. Intent is evident through method names and Javadoc. The code is concise, with each line performing a distinct action, though the ternary operator for constructing FaultHandlerException could be slightly more readable. Reading flow is natural and logical. Minor deductions: the ternary expression packs multiple operations into one line, and the method handleFault could be simplified with a helper method for exception creation. Overall, this is highly readable test utility code.
Run 3
The code is well-structured with clear separation of concerns and logical organization. The class has a single responsibility and methods are concise. Nesting is minimal with only one level in the handleFault method. Intent is clear from descriptive method names and the class-level Javadoc. The ternary operator for exception creation slightly reduces readability compared to an if-else block, but is still understandable. Action granularity is good—most lines perform one logical operation. Reading flow is natural with the constructor first, then the main handler, then utility methods. The only minor issues are the slightly long ternary expression and the unused 'ignore' field in 'maybeRethrowFirstException' could be clearer about its purpose. Overall, this is highly readable test utility code.
Run 1
Code Structure: Fields, constructor, fault handling, and accessors are logically organized into focused methods. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: Descriptive method names and the class documentation clearly explain first-fault capture and optional rethrowing; the variable 'e' and flag 'ignore' could be more specific. Code length: Compact and appropriate, with only minor repetition in logging and exception-message construction. Action granularity: Each statement generally performs one action, though the multiline ternary combines exception selection and construction. Reading flow: Consistent formatting and straightforward method order support natural reading; the ternary and wrapped string concatenation slightly interrupt the flow.
Run 2
Code Structure: Well-organized class with fields, constructor, and focused methods. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: Descriptive names and the class comment clearly explain first-fault capture and optional rethrowing; the generic local name 'e' is slightly less informative. Code length: Compact and proportionate, though exception construction repeats message assembly. Action granularity: Statements generally perform one action each. Reading flow: Methods follow a natural sequence from handling faults to rethrowing, accessing state, and configuring behavior. The multiline ternary and concatenated exception message slightly interrupt otherwise straightforward reading.
Run 3
Code Structure: Well-organized class with fields, constructor, fault handling, and small accessor/control methods. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Descriptive names and the class documentation clearly communicate that the first fault is retained for testing; the scope of the ignore flag could be clearer. Code length: Concise overall, though repeated null checks and exception-message construction add minor duplication. Action granularity: Statements generally perform one action each; the multiline ternary combines exception selection and message construction, slightly increasing reading effort. Reading flow: Methods follow a natural progression, with consistent formatting and straightforward control flow. The ternary expression is the main readability distraction.