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, cause);
} else {
log.error("Encountered {} fault: {}", name, failureMessage);
}
FaultHandlerException e = (cause == null) ?
new FaultHandlerException(name + ": " + failureMessage) :
new FaultHandlerException(name + ": " + failureMessage +
": " + cause.getMessage(), cause);
if (!((firstException == null))) {} else {
firstException = e;
}
return firstException;
}
public synchronized void maybeRethrowFirstException() {
if (!((firstException != null && !ignore))) {} else {
throw firstException;
}
}
public synchronized FaultHandlerException firstException() {
return firstException;
}
public synchronized void setIgnore(boolean ignore) {
this.ignore = ignore;
}
}
Run 1
The code has clear class-level intent and is relatively short, but readability suffers from several issues. The if-else conditions are inverted and use double negatives like `if (!((cause == null)))`, which makes the logic unnecessarily hard to follow. Several empty if blocks with else-only logic (`if (!((firstException == null))) {} else { ... }`) are confusing and violate action granularity. Nesting is shallow, which is good, and the class structure is logical. However, reading flow is disrupted by these awkward conditionals and empty blocks. The ternary operator for exception creation is acceptable but combined with the inverted conditions adds cognitive load. Variable naming is clear, and logging is appropriately placed. Overall, the code needs refactoring for clarity of intent and more natural conditionals to reach good readability.
Run 2
The code has a clear purpose and decent structure, but readability is hampered by awkward conditional logic, unnecessary nesting, and a confusing return value in handleFault. The use of 'if (!((...))) {} else {...}' patterns is obscure and should be simplified to straightforward 'if (...) {...} else {...}'. The method handleFault returns the stored first exception rather than the newly created one, which is non-intuitive and makes the code harder to follow. Some lines combine multiple actions or are excessively long. The logging and exception creation could be more concise. Overall, the code is understandable but would benefit from cleaner conditional expressions and clearer intent.
Run 3
The code has a clear class-level purpose and good logging, but several choices hurt readability. The conditionals like `if (!((cause == null)))` and `if (!((firstException == null))) {} else { ... }` are inverted and awkward, forcing the reader to mentally negate expressions. Empty `if` blocks before `else` statements are confusing and add unnecessary nesting. The ternary expression for creating `FaultHandlerException` is compact but reduces clarity compared to a simple if-else. Action granularity is mostly fine, but the overall reading flow suffers from unnatural condition ordering. Structurally, the class is short and single-purpose, and method names are descriptive. Reducing the negated conditions and empty blocks would immediately improve readability to a higher level.
Run 1
Code Structure: Fields, constructor, and focused methods are logically organized. Nesting: Control flow is shallow, but empty if branches followed by else blocks add needless complexity. Clarity of intent: Descriptive names and the class comment explain the purpose, while redundant parentheses and negated conditions obscure straightforward null checks and rethrow logic. Code length: The class is compact, though several conditional expressions could be simplified. Action granularity: Most lines perform one action; the multiline exception construction remains understandable. Reading flow: Method order is natural, but inverted checks, empty branches, and the wrapped ternary interrupt otherwise clean reading.
Run 2
Code Structure: Fields, constructor, and focused methods are logically organized. Nesting: Control flow is shallow, but empty if branches followed by else blocks add avoidable complexity. Clarity of intent: Class documentation and method names explain the purpose well; redundant parentheses and negated conditions obscure straightforward null checks and rethrow logic. Code length: The class is compact, though repeated logging branches and awkward conditional forms introduce unnecessary verbosity. Action granularity: Most lines perform one action, with no dense sequences of statements; the multiline exception-construction ternary is somewhat harder to scan. Reading flow: The overall progression is natural, but inverted conditions, empty blocks, and wrapped string concatenation interrupt readability.
Run 3
Code Structure: Fields, constructor, and small methods are logically organized with clear responsibilities. Nesting: Control flow is shallow, but empty if branches followed by else blocks obscure simple conditions. Clarity of intent: Descriptive method names and the class comment explain the purpose; redundant parentheses and negated conditions make exception handling harder to understand. Code length: Mostly concise, though unnecessary conditional syntax and repeated exception-message construction add clutter. Action granularity: Statements generally perform one action per line; compressed empty branches reduce visual clarity. Reading flow: The overall progression is natural, but inverted null checks, empty branches, and a multiline ternary interrupt straightforward reading.