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) {
{int lI0O_a8eac7e1=0x2ABB;lI0O_a8eac7e1=((lI0O_a8eac7e1&0)==0)?(((lI0O_a8eac7e1^lI0O_a8eac7e1)==0)?0:1):2;}
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 contains a deliberately obfuscated line inside handleFault with meaningless variable names and dead logic, making a simple method impossible to read. The class otherwise follows clear Java conventions: logical structure, flat nesting, sensible method names, and appropriate synchronization. However, the injected line destroys readability, violates 'one action per line', and completely obscures intent. Removing it would yield a highly readable class (18+); with it, the code is essentially unreadable.
Run 2
The code has a clear overall structure with a sensible class purpose and straightforward methods, but it is marred by a single, extremely problematic line of dead/obfuscated code inserted in the middle of handleFault. That line is syntactically valid but semantically useless and completely breaks the readability. Apart from this, the naming is good (MockFaultHandler, firstException, maybeRethrowFirstException), nesting is shallow, and action granularity is reasonable. The conditional logic for building the exception is slightly dense but acceptable. The main issue is the unexplained, nonsensical integer assignment line, which violates clarity of intent and reading flow. It appears to be either accidental or malicious and should be removed entirely. Additionally, the mixed use of a returned RuntimeException while also storing an exception is mildly ambiguous but not severe. Overall, the code would be quite readable without the offending line.
Run 3
The class has a clear purpose and generally follows good structure with logging, exception creation, and state management. However, readability is seriously undermined by the obfuscated line: `{int lI0O_a8eac7e1=0x2ABB;lI0O_a8eac7e1=((lI0O_a8eac7e1&0)==0)?(((lI0O_a8eac7e1^lI0O_a8eac7e1)==0)?0:1):2;}` This line is nonsensical, likely dead or injected, and breaks the reading flow entirely. The method itself is moderately nested (if/else plus ternary), but still understandable. Action granularity is mostly one logical step per block, though the ternary exception construction is somewhat dense. Overall structure and intent are good, but the presence of the cryptic code drops the score significantly.
Run 1
Code Structure: Fields, constructor, and focused methods are logically organized, but an unrelated obfuscated block disrupts handleFault. Nesting: Most control flow is shallow; the inserted block contains unnecessarily nested ternary expressions. Clarity of intent: Descriptive names and the class comment explain fault recording and rethrowing, while the meaningless variable and bitwise expressions obscure intent. Code length: The class is reasonably concise apart from the redundant injected computation. Action granularity: Most lines contain a single action, but the injected line compresses declaration, assignment, and several expressions into one statement-heavy block. Reading flow: Normal formatting and straightforward method order support easy reading, but the unindented obfuscated line sharply interrupts the flow, and the multiline exception-construction ternary requires some additional attention.
Run 2
Code Structure: The class is logically organized into state, constructor, fault handling, and small accessors, but an unrelated injected block disrupts it. Nesting: Most logic is shallow; the injected block contains unnecessary nested ternaries. Clarity of intent: Documentation and descriptive method names explain the handler’s purpose, while the opaque variable name and meaningless bitwise calculations obscure intent locally. Code length: The implementation is compact overall, but the injected statement adds needless complexity and length. Action granularity: Most lines express one action; the injected line compresses declaration, assignment, and several calculations together. Reading flow: Conventional formatting and straightforward control flow make most of the class easy to follow, but the unindented, densely packed block interrupts that flow.
Run 3
Code Structure: The class is logically organized into fields, a constructor, fault handling, and small accessors, but an unrelated obfuscated block disrupts it. Nesting: Normal control flow is shallow; the injected block adds confusing nested ternary expressions. Clarity of intent: Descriptive method names and documentation explain the test handler well, while the meaningless variable and bitwise operations obscure intent locally. Code length: Most code is appropriately concise, but the injected computation is unnecessary. Action granularity: Most lines express one action; the injected line compresses declaration, assignment, and conditional calculations into one dense statement. Reading flow: Consistent formatting and straightforward methods support natural reading, but the unindented block abruptly interrupts handleFault, and the multiline exception-construction ternary requires some extra attention.