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 difficult to read due to severe formatting issues that violate basic readability principles. Multiple import statements are compressed onto single lines, and class members, methods, and braces are jumbled together without proper line breaks. This creates a disorganized structure that obscures the logical organization of the code. The nesting is somewhat flat, but the lack of proper indentation and line breaks makes the control flow hard to follow. Action granularity is poor, with multiple operations crammed onto single lines, forcing readers to work harder to identify individual steps. The reading flow is severely disrupted by inconsistent spacing and missing newlines between methods and fields. While the class purpose is stated in the JavaDoc, the implementation details are obscured. The code length itself is reasonable, but the poor formatting negates any benefit from conciseness. Overall, the code functions but demonstrates a critical lack of attention to formatting conventions that are essential for maintainability and collaboration.
Run 2
The code has fundamental readability issues. The structure is tangled: multiple statements are crammed onto single lines, method declarations are followed by other code on the same line, and closing braces are mixed with subsequent statements. This creates a disorganized visual flow that forces the reader to parse dense clusters of text rather than scanning cleanly. While the logic itself is simple (store first fault, optionally ignore), the formatting obscures the intent. Nesting is shallow but presented in a way that feels deeply cluttered due to collapsed lines. Action granularity violates the 'one action per line' principle repeatedly. The class-level Javadoc is clear, and method names are reasonable, but the overall presentation makes the code unnecessarily difficult to read. Proper formatting with consistent line breaks, one statement per line, and separated method declarations would significantly improve readability.
Run 3
The code is poorly structured with multiple statements collapsed onto single lines, inconsistent brace placement, and confusing line breaks in string concatenation. While the class purpose is documented and method names are clear, the formatting severely impairs readability. Nesting is minimal, which is good, but action granularity is violated by having multiple statements per line. Reading flow is disorganized due to inconsistent spacing and line breaks within the ternary expressions and constructors. The logic is relatively simple, but the presentation makes it harder to scan than necessary.
Run 1
Code Structure: The class logically groups fault handling, exception retrieval, and configuration, but cramped formatting obscures method and field boundaries. Nesting: Shallow conditionals keep control flow simple. Clarity of intent: Descriptive names and the class comment clearly explain recording and optionally rethrowing the first fault; the long ternary slightly complicates exception construction. Code length: Concise overall, with little unnecessary code, though brevity comes at the expense of whitespace. Action granularity: Multiple imports, declarations, and statements share lines, making individual operations harder to distinguish. Reading flow: Inconsistent brace placement, awkward line breaks, and adjacent method definitions interrupt otherwise straightforward execution flow.
Run 2
Code Structure: The class logically groups fault handling, stored exception access, and ignore configuration, but compressed declarations and method boundaries obscure that organization. Nesting: Shallow conditionals make control flow easy to understand. Clarity of intent: Descriptive names and the class documentation clearly explain the purpose, although the long exception-construction ternary requires extra attention. Code length: The implementation is appropriately short without substantial redundancy. Action granularity: Multiple imports, fields, statements, and method boundaries share lines, making individual actions harder to distinguish. Reading flow: Inconsistent brace placement, awkward line breaks, and crowded formatting interrupt otherwise straightforward logic. Overall, the behavior is understandable, but formatting significantly reduces readability.
Run 3
Code Structure: The class logically groups state and fault-handling methods, but compressed formatting obscures member boundaries. Nesting: Shallow conditionals keep control flow simple. Clarity of intent: Descriptive method names and the class comment clearly explain first-fault capture and optional rethrowing; the exception-construction ternary is harder to scan. Code length: The implementation is concise without substantial redundancy, although excessive compression reduces readability. Action granularity: Multiple imports, declarations, and statements share lines, violating one-action-per-line formatting. Reading flow: Inconsistent brace placement, indentation, and line breaks interrupt otherwise straightforward execution and make transitions between methods difficult to follow.