Source code
package org.apache.kafka.controller.errors;
import org.apache.kafka.common.errors.NotControllerException;
import org.apache.kafka.common.errors.TimeoutException;
import java.util.OptionalInt;
import java.util.concurrent.ExecutionException;
public class ControllerExceptions {
/**
* Check if an exception is a normal timeout exception.
*
* @param exception The exception to check.
* @return True if the exception is a timeout exception.
*/
public static boolean a(Throwable a) {
if (a == null) return false;
if (a instanceof ExecutionException) {
a = a.getCause();
if (a == null) return false;
}
return a instanceof TimeoutException;
}
/**
* Create a new exception indicating that the controller is in pre-migration mode, so the
* operation cannot be completed.
*
* @param controllerId The current controller.
* @return The new NotControllerException.
*/
public static NotControllerException b(OptionalInt b) {
if (b.isPresent()) {
return new NotControllerException("The controller is in pre-migration mode.");
} else {
return new NotControllerException("No controller appears to be active.");
}
}
/**
* Create a new exception indicating that current node is not the controller.
*
* @param controllerId The current controller.
* @return The new NotControllerException.
*/
public static NotControllerException c(OptionalInt c) {
if (c.isPresent()) {
return new NotControllerException("The active controller appears to be node " +
c.getAsInt() + ".");
} else {
return new NotControllerException("No controller appears to be active.");
}
}
}
Run 1
The code has minimal nesting, one action per line, and concise methods. However, readability is severely impacted by poor naming: method names like 'a', 'b', 'c' and parameters like 'a', 'b', 'c' obscure intent despite Javadoc. The first method relies on mutation of the parameter, which harms clarity. Javadoc for the last two methods mentions 'controllerId' but parameters are only OptionalInt named 'b'/'c', creating inconsistency. The ternary-like if/else returns are clear but seem repetitive across methods. Overall structure is logical but clarity of intent and reading flow suffer due to cryptic identifiers and misleading documentation, making it difficult to understand without extra effort.
Run 2
The code structure is logical overall but suffers from poor naming conventions (a, b, c for methods and parameters) that obscure intent. Nesting is shallow, which is good, but the first method mutates its parameter and branches unnecessarily, adding to confusion. The length is concise and actions are mostly granular, but readability is harmed by unclear method/parameter names despite Javadoc. Formatting, such as line breaks in string concatenation, could be improved. The reading flow is somewhat natural but the cryptic identifiers and inconsistent style make it harder to follow.
Run 3
The code has a clear structure and relatively flat nesting, with only one level of conditionals. The methods are concise and mostly perform one action per line. However, readability is significantly reduced by poor naming: methods `a`, `b`, and `c` and parameters `a`, `b`, `c` convey no intent despite the Javadoc. The first method mutates its parameter, which can confuse readers. The second and third methods are very similar, and their difference relies on subtle message wording rather than distinct logic. The reading flow is natural enough but hampered by meaningless identifiers. Renaming methods to something like `isTimeoutException`, `preMigrationNotControllerException`, and `notControllerException` would greatly improve clarity without changing structure.
Run 1
1. Code Structure: Three small, logically separated methods provide clear organization. 2. Nesting: Shallow conditionals and early returns keep complexity low. 3. Clarity of intent: Documentation and exception messages explain behavior, but single-letter method and parameter names obscure meaning; @param names also mismatch actual parameters. 4. Code length: Concise overall, with minor repetition and unnecessary else branches after returns. 5. Action granularity: Most lines contain one action, although inline null checks combine conditions and returns. 6. Reading flow: Straightforward control flow and consistent formatting support easy reading, but cryptic identifiers force reliance on documentation.
Run 2
Code Structure: Three separate methods organize distinct exception-handling tasks logically. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive exception messages and documentation explain purpose, but single-letter method and parameter names obscure meaning; Javadoc parameter names also fail to match actual signatures. Code length: The implementation is concise, although else branches after returns are unnecessary. Action granularity: Most lines contain one action; inline null-check returns slightly compress condition and action. Reading flow: Methods follow straightforward checks and returns, but poor naming and inconsistent spacing between package, imports, and class reduce readability.
Run 3
Code Structure: Three focused utility methods are logically organized and independent. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Descriptive comments and exception messages explain behavior, but method and parameter names a, b, and c obscure intent; Javadoc parameter names also do not match the signatures. Code length: Short implementations are appropriate, though else blocks after returns are unnecessary. Action granularity: Most lines contain one action, but inline null checks combine conditions and returns on a single line. Reading flow: Consistent formatting and straightforward branching support natural reading, while cryptic identifiers and mismatched documentation interrupt comprehension.