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 user) {
this.name = user;
}
@Override
public synchronized RuntimeException refreshUser(String pendingMessage, Throwable event) {
if (event == null) {
log.error("Encountered {} fault: {}", name, pendingMessage);
} else {
log.error("Encountered {} fault: {}", name, pendingMessage, event);
}
FaultHandlerException age = (event == null) ?
new FaultHandlerException(name + ": " + pendingMessage) :
new FaultHandlerException(name + ": " + pendingMessage +
": " + event.getMessage(), event);
if (firstException == null) {
firstException = age;
}
return firstException;
}
public synchronized void validateRequest() {
if (firstException != null && !ignore) {
throw firstException;
}
}
public synchronized FaultHandlerException refreshRequest() {
return firstException;
}
public synchronized void sendToken(boolean result) {
this.ignore = result;
}
}
Run 1
The code is functional but suffers from poor readability. Key issues: method names like 'refreshUser', 'validateRequest', 'refreshRequest', and 'sendToken' do not match their actual behavior (e.g., 'refreshUser' actually logs and stores a fault). The variable names 'user', 'age', and 'result' are misleading or vague. The ternary operators in 'refreshUser' are dense and hard to parse. While the structure is flat and logically organized, the intent is unclear due to misleading naming. Action granularity and reading flow are acceptable but the semantic mismatch between names and behavior significantly hurts comprehension. The class javadoc helps, but does not compensate for the confusing API design.
Run 2
The code is generally readable with good structure: it's a small, focused test utility with clear Javadoc and consistent synchronization. However, the method naming is confusing relative to the FaultHandler interface semantics - 'refreshUser', 'refreshRequest', and 'sendToken' don't align with their actual behaviors (storing first exception, retrieving it, setting ignore flag). The variable name 'age' for an exception is unclear. The repeated ternary logic for constructing FaultHandlerException adds slight verbosity though it keeps one action per line. Overall nesting is flat, intent is mostly clear from context, but naming choices reduce clarity.
Run 3
The code is generally well-structured and readable. It follows a clear logical organization with a single class, a concise Javadoc comment, and methods that each perform one focused action. Nesting is minimal, with only one level inside Methods. Clarity of intent is mostly good, though some method names such as 'refreshUser' and 'sendToken' are ambiguous in a test mock context, and variable names like 'user', 'pendingMessage', and 'age' could be clearer. Code length is concise and not unnecessarily long. Action granularity is reasonable, with occasional compressed logic (e.g., the ternary in refreshUser and string concatenation). The reading flow is natural, starting with fields and constructor, then overridden methods. Overall, it is readable but not perfectly self-documenting due to naming choices.
Run 1
Code Structure: Fields, constructor, and small methods are logically organized, with fault recording separated from validation and configuration. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: The class documentation explains the purpose, but refreshUser, validateRequest, refreshRequest, sendToken, and age are misleading names for fault-handling operations. The documentation also references handleFault, which is absent, creating confusion. Code length: Compact overall, although exception construction repeats the null check and message prefix. Action granularity: Most statements perform one action; the multiline ternary combines message construction and exception creation but remains manageable. Reading flow: Logging, exception creation, first-fault storage, and return follow a natural sequence, though inconsistent naming and the wrapped ternary interrupt comprehension.
Run 2
Code Structure: The class is logically organized into fields, a constructor, fault processing, validation, and accessors. Nesting: Shallow conditionals make control flow easy to follow. Clarity of intent: The documentation explains first-fault storage, but misleading names such as refreshUser, validateRequest, refreshRequest, sendToken, and age obscure actual responsibilities. The documentation also references handleFault, which does not appear in the class. Code length: Compact overall, though exception construction repeats the null check and message formatting. Action granularity: Most statements perform one action; the multiline ternary combines message construction and exception creation, requiring extra attention. Reading flow: Method ordering is sensible and formatting is consistent, but inconsistent domain terminology and the missing separation between the package declaration and imports reduce readability.
Run 3
Code Structure: Fields, constructor, and methods are logically organized, with clear separation of responsibilities. Nesting: Shallow conditionals keep control flow easy to follow. Clarity of intent: The class documentation explains first-fault retention, but method names such as refreshUser, validateRequest, refreshRequest, and sendToken obscure fault-handling behavior. Variable names age, user, and result are similarly misleading, and the documentation references handleFault rather than the implemented method. Code length: Compact overall, although repeated exception-message construction adds minor verbosity. Action granularity: Statements generally perform one action each; the multiline ternary combines exception selection and construction but remains manageable. Reading flow: Logging, exception creation, first-exception storage, and return follow a natural sequence. Consistent formatting and synchronization help readability, but misleading naming and the documentation mismatch significantly weaken understanding.