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 highly readable with clear structure and logical organization. It implements a simple interface with well-named methods and fields that accurately describe their purpose. Nesting is minimal—only one conditional level in handleFault. The ternary expressions are concise but could be slightly clearer with extracted variables. Single responsibility per method is maintained, and action granularity is appropriate. Reading flow follows natural progression from construction to fault handling to status queries. The class javadoc clearly explains test-specific behavior. Minor deductions: the ternary for exception construction is slightly dense, but overall the code is exemplary.
Run 3
The code is well-structured and readable. It follows a clear logical organization with fields, constructor, and methods grouped naturally. The class has a single responsibility and a clear purpose via its Javadoc. Nesting is minimal, with only one level inside the methods. Clarity of intent is high: method names like maybeRethrowFirstException and setIgnore communicate behavior effectively. Code length is appropriate—not excessively verbose. Action granularity is mostly one action per line, though the ternary expression for constructing FaultHandlerException combines logic on a single line, slightly reducing readability. Reading flow is natural, moving from logging to exception creation, storage, and rethrowing. Minor improvements could include extracting the exception creation into a helper method and simplifying the ternary for better readability. Overall, the code is clean, maintainable, and easy to follow.
Run 1
Code Structure: Fields, constructor, fault handling, and accessors are logically organized into focused methods. Nesting: Shallow conditionals make control flow easy to follow. Clarity of intent: The class documentation and descriptive method names clearly communicate its testing purpose and first-fault behavior, though 'ignore' and 'e' could be more descriptive. Code length: Compact and proportionate to its functionality, with minimal repetition. Action granularity: Statements generally perform one action each; the multiline ternary combines exception selection and construction, slightly increasing reading effort. Reading flow: Execution proceeds naturally from logging to exception construction, first-exception storage, and return. Consistent formatting helps, although a blank line after the package declaration and a simpler presentation of exception construction would improve readability.
Run 2
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 names and the class comment clearly communicate first-fault capture and optional rethrowing; the name 'ignore' is slightly vague about what is suppressed. Code length: Compact and appropriately sized, with minor repetition in logging and exception construction. Action granularity: Statements generally perform one action each, although the multiline ternary combines conditional selection, message assembly, and exception creation. Reading flow: Consistent formatting and straightforward method order support natural reading; the wrapped ternary and string concatenation introduce a small readability burden.
Run 3
Code Structure: The class is logically organized into fields, constructor, fault handling, and small accessor/control methods. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Descriptive method names and the class comment clearly communicate first-fault retention and optional rethrowing; the generic variable name 'e' and 'ignore' flag are slightly less explicit. Code length: Compact and appropriate, with little unnecessary code. Action granularity: Each statement performs a distinct action, although exception construction combines conditional selection and message assembly. Reading flow: The sequence of logging, constructing, storing, and returning the first exception is natural. The multiline ternary and string concatenation modestly interrupt readability.