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 nam) {
this.name = nam;
}
@Override
public synchronized RuntimeException handle(String failure, Throwable cau) {
if (cau == null) {
log.error("Encountered {} fault: {}", name, failure);
} else {
log.error("Encountered {} fault: {}", name, failure, cau);
}
FaultHandlerException e = (cau == null) ?
new FaultHandlerException(name + ": " + failure) :
new FaultHandlerException(name + ": " + failure +
": " + cau.getMessage(), cau);
if (firstException == null) {
firstException = e;
}
return firstException;
}
public synchronized void maybe() {
if (firstException != null && !ignore) {
throw firstException;
}
}
public synchronized FaultHandlerException first() {
return firstException;
}
public synchronized void set(boolean ign) {
this.ignore = ign;
}
}
Run 1
The code is well-structured and readable. Methods are short, focused, and have clear intent, following a natural flow with good naming conventions. Nesting is minimal, and the class has logical organization. However, some parameter names are abbreviated ('nam', 'cau', 'ign'), reducing clarity. The conditional expression for creating FaultHandlerException could be slightly more readable if formatted differently. The maybe() method's name is ambiguous without context. The code is concise but could benefit from slightly more descriptive naming and minor formatting improvements, making it a 16 out of 20.
Run 2
The code is generally clear and well-structured with a logical class layout. It has a single-purpose class with flat nesting and straightforward methods. However, readability is reduced by poor parameter naming (`nam`, `cau`, `ign`) and method names (`maybe`, `set`) that do not clearly communicate intent. The conditional logging and exception construction create some visual clutter, and the action granularity is slightly compressed in places. Overall, the class is concise but could be improved with more descriptive naming and slightly more spacing for readability.
Run 3
The code is generally structured and readable: it has a clear class purpose, Javadoc, simple fields, and flat, mostly understandable methods. However, readability is undermined by poor parameter names ('nam', 'cau', 'ign'), which obscure intent and introduce ambiguity. The 'handle' method contains a few multi-step lines and nested ternary logic that slightly harms readability. The 'maybe' method name is unclear; it would be better as 'maybeThrow' or 'checkAndThrow'. While the class is concise and avoids deep nesting, naming choices and lack of clear action separation bring the score down.
Run 1
Code Structure: Fields, constructor, and small methods are logically organized, with fault handling concentrated in one method. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: The class documentation and firstException field explain the main purpose, but names such as nam, cau, e, maybe, first, and set obscure parameter meanings and method behavior. The documentation also references handleFault rather than handle. Code length: Compact without substantial unnecessary code, although exception construction is somewhat visually dense. Action granularity: Statements generally perform one action per line; the multiline ternary combines branching, string construction, and object creation. Reading flow: The overall progression is natural, but abbreviated names, generic accessor names, and the wrapped ternary interrupt readability.
Run 2
Code Structure: Fields, constructor, fault handling, and accessors are logically organized. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: The class documentation and firstException field explain the main purpose, but vague method names (maybe, first, set) and abbreviated parameters (nam, cau, ign) obscure behavior. The documentation also references handleFault rather than the actual handle method. Code length: Compact and generally appropriate, though cause checking is repeated. Action granularity: Each statement performs a focused action, with no crowded multi-statement lines. Reading flow: Mostly natural, but the multiline ternary and message concatenation require extra attention. More descriptive names and slightly cleaner exception construction would improve readability.
Run 3
Code Structure: Fields, constructor, fault handling, and accessor methods are logically organized. Nesting: Shallow conditionals keep the code easy to follow. Clarity of intent: The class documentation and descriptive fields help, but method names such as maybe, first, and set, plus abbreviated parameters nam, cau, and ign, obscure intent. The documentation references handleFault rather than the actual handle method. Code length: Compact and mostly appropriate, though fault logging and exception construction repeat the null-cause distinction. Action granularity: Statements generally perform one action each; the multiline ternary requires slightly more effort to parse. Reading flow: Execution proceeds naturally from logging to exception construction, first-exception storage, and return, with minor friction from terse naming and the wrapped conditional expression.