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;
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 with clear separation of concerns and a logical organization. Package and imports are clean, though extra blank lines exist. Nesting is minimal, with only a few if-else branches. Intent is clear for a mock fault handler, but the handleFault logic could be slightly more explicit about why it always returns the first exception. Code length is concise but the ternary expression for creating FaultHandlerException is a bit dense. Action granularity is mostly good, but the exception creation line combines multiple operations. Reading flow is natural: constructor, fault handling, then helper methods. The synchronized keyword on every method is consistent. Minor improvements could include extracting the exception creation to a helper method and documenting the 'ignore' flag's purpose. Overall, highly readable code with only minor areas for polish.
Run 2
The code is well-structured and readable. It follows a logical organization: class fields, constructor, then overridden methods and public accessors/mutators. Nesting is minimal—only shallow if/else blocks and one ternary. Intent is clear: the class mocks fault handling by recording the first exception and optionally rethrowing it. The method and field names are descriptive. Code length is concise; no unnecessary verbosity. Action granularity is mostly one action per line, except for the ternary expression spanning multiple lines, which remains readable. Reading flow is natural and consistent with Java conventions. Minor deductions: the ternary is slightly complex due to conditional message construction, and import/blank line formatting is inconsistent, but neither significantly harms clarity.
Run 3
The code is well-structured and highly readable. It follows a clear, logical organization with fields, constructor, override method, and helper methods clearly separated. Nesting is minimal — only simple if/else and conditional expressions, with no deep indentation. Intent is obvious from clear method and variable names like `handleFault`, `maybeRethrowFirstException`, and `firstException`. The code is concise without being cryptic, and no unnecessary repetition exists. Action granularity is appropriate: most lines perform a single action, such as logging, constructing the exception, or assigning it. Reading flow is natural, progressing from logging to exception creation to state storage. Minor improvements could include breaking the ternary-based exception construction into a small helper or adding a brief comment explaining the 'first exception' retention behavior, but overall the code is almost exemplary in clarity and maintainability.
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: Descriptive class and method names clearly communicate recording the first fault and optionally rethrowing it; the local variable 'e' and field 'ignore' could be more specific. Code length: Compact overall, though excess blank lines and repeated null checks add minor clutter. Action granularity: Statements generally perform one action each; the multiline ternary combines exception construction and message formatting but remains understandable. Reading flow: The sequence from logging to exception creation, storage, and return is natural. Consistent formatting and synchronization declarations support readability, with the ternary expression slightly interrupting the otherwise straightforward flow.
Run 2
Code Structure: Fields, constructor, fault handling, and supporting methods are logically organized. Nesting: Shallow conditionals make execution easy to follow. Clarity of intent: Descriptive class and method names clearly communicate recording and optionally rethrowing the first fault; the local variable 'e' and flag 'ignore' could be more specific. Code length: Compact overall, though excessive blank lines before the class and repeated exception-message construction add minor clutter. Action granularity: Statements generally perform one action each, with exception construction slightly denser due to a multiline ternary and string concatenation. Reading flow: Logging, exception creation, first-fault retention, and return occur in a natural sequence. Consistent formatting and short methods support readability.
Run 3
Code Structure: Fields, constructor, fault handling, and helper methods are logically organized. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: Descriptive class and method names clearly convey recording and optionally rethrowing the first fault, though 'ignore' and 'e' could be more specific. Code length: Compact overall, with minor repetition in logging and exception construction and unnecessary blank lines before the class. Action granularity: Each statement performs a distinct action; there are no crowded multi-statement lines. Reading flow: The progression from logging to exception creation, first-exception storage, and return is natural. The multiline ternary and concatenated exception message slightly interrupt readability.