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 generally well-structured and readable. It follows a logical organization with clear field declarations, a straightforward constructor, and focused methods. Nesting is minimal (one level for the null checks), and the intent is mostly clear, especially with the useful Javadoc explaining the class's purpose for testing. The class is concise, avoiding unnecessary methods or comments. Action granularity is reasonable — while the `handleFault` method contains a few statements, they are closely related to fault handling and do not feel overloaded. Reading flow is natural, with a logical progression from field declarations to methods. Minor deductions: the `handleFault` method's conditional logging and exception construction could be slightly more compact, and the ternary expressions are acceptable but could be extracted for readability. Overall, the code is clean and maintainable.
Run 3
The code is well-structured, with a clear class purpose and logical organization. Nesting is minimal, limited to an if-else in handleFault. Intent is explicit through descriptive method names and Javadoc. Code length is concise without sacrificing clarity. Each line generally performs one action, though the ternary operator construction of FaultHandlerException spans multiple lines but remains readable. The reading flow is natural, moving from fields to constructor to methods in a logical order. Minor opportunities for improvement include extracting the FaultHandlerException creation for enhanced clarity and slightly reducing ternary complexity.
Run 1
Code Structure: Fields, constructor, and focused methods are logically organized. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: The class documentation and descriptive method names clearly communicate first-fault capture and optional rethrowing; the variable name 'e' and flag 'ignore' could be more specific. Code length: Compact and appropriately sized, with only minor duplication in logging and exception construction. Action granularity: Statements generally perform one action each, though the multiline ternary combines exception selection, construction, and message formatting. Reading flow: The progression from logging to exception creation, first-exception storage, and return is natural. The ternary expression slightly interrupts an otherwise straightforward reading experience.
Run 2
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: Descriptive method names and the class comment clearly convey first-fault recording and optional rethrowing; the generic variable name 'e' and 'ignore' flag are slightly less explicit. Code length: Compact and appropriate, with minor repetition in null-cause handling. Action granularity: Each statement performs a distinct action, although the multiline ternary combines exception construction with message assembly. Reading flow: Execution proceeds naturally from logging to exception creation, first-exception storage, and return. Consistent formatting supports readability, but the multiline ternary and concatenated message require slightly more effort to parse.
Run 3
Code Structure: Fields, constructor, fault handling, and accessors are logically organized into a cohesive class. Nesting: Simple conditionals keep nesting shallow. Clarity of intent: The class documentation and descriptive method names clearly convey its testing purpose and first-exception behavior; the local name 'e' and flag 'ignore' are slightly less explicit. Code length: The implementation is concise, with little unnecessary code, although cause-null checks are repeated. Action granularity: Statements generally perform one action each; the multiline ternary combines exception construction with message formatting, adding modest reading effort. Reading flow: The progression from logging to exception creation, storage, and return is natural, followed by straightforward supporting methods. The wrapped ternary is the main readability weakness.