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 validateBalance(Throwable nextState) {
if (nextState == null) return false;
if (nextState instanceof ExecutionException) {
nextState = nextState.getCause();
if (nextState == null) return false;
}
return nextState 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 validateMessage(OptionalInt defaultOrder) {
if (defaultOrder.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 validateSession(OptionalInt currentBatch) {
if (currentBatch.isPresent()) {
return new NotControllerException("The active controller appears to be node " +
currentBatch.getAsInt() + ".");
} else {
return new NotControllerException("No controller appears to be active.");
}
}
}
Run 1
The code is well-structured with clear separation of methods and Javadoc comments. However, there are issues that impact readability: method names are misleading - 'validateBalance', 'validateMessage', and 'validateSession' don't reflect their actual behavior (checking for timeout, creating exceptions for missing controller). The parameter names are also confusing ('nextState', 'currentBatch', 'defaultOrder') and don't match the Javadoc parameters described. Nesting is minimal and the flow is generally clear, but the semantic mismatch between names and purpose makes the code harder to understand than it should be. The if-else blocks could be simplified with ternaries for conciseness. Overall, the structure is solid but naming choices significantly reduce clarity of intent.
Run 2
The code has a clear, logical structure with each method handling a distinct exception-related scenario, and the use of early returns in 'validateBalance' keeps nesting flat. However, readability is significantly hampered by misleading method names ('validateBalance', 'validateMessage', 'validateSession') that do not reflect their actual purposes, and parameter names ('nextState', 'defaultOrder', 'currentBatch') that are semantically unrelated to their roles. The Javadoc comments are also inconsistent and sometimes inaccurate, mentioning parameters that do not exist or mislabeling behavior. While the code is concise and actions are generally one per line, the ambiguous naming and documentation confuse intent, making it harder to understand what each method actually does.
Run 3
The code has clear structure with separated methods and Javadoc, but suffers from misleading method names (e.g., `validateBalance` checking timeouts, `validateMessage` returning an exception), ambiguous parameter names (e.g., `nextState` for an exception, `defaultOrder` for a controller ID), and inconsistent naming patterns. Nesting is mostly flat, and action granularity is reasonable with concise lines. However, the reading flow is disrupted by the mismatch between method names and their actual behavior. The `ExecutionException` unwrapping logic is clear but could be extracted for clarity. Overall, the code is readable syntactically but semantically confusing due to poor naming and documentation inconsistencies, making intent harder to grasp than necessary.
Run 1
Code Structure: Three small, separate methods provide logical organization, though import grouping and spacing could improve. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: The main weakness is misleading naming; validateBalance, validateMessage, and validateSession do not describe their actual operations, and nextState, defaultOrder, and currentBatch obscure parameter roles. Javadoc helps explain intent, but its @param names do not match the method signatures. Code length: Concise overall, with minor duplication in exception creation and unnecessary else branches after returns. Action granularity: Most lines perform one action, although inline null checks combine a condition and return. Reading flow: Straightforward control flow and clear exception messages make the implementation easy to follow, but inconsistent terminology forces readers to reconcile names with behavior.
Run 2
Code Structure: Three small, separate methods organize distinct exception-handling tasks logically. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: The main weakness is misleading naming: validateBalance checks for timeouts, while validateMessage and validateSession create exceptions; parameter names also obscure their roles. Javadoc helps explain purpose, but @param names do not match the actual parameters. Code length: Compact overall, with minor repetition in exception construction and unnecessary else branches after returns. Action granularity: Each statement performs one action, although inline null checks slightly compress presentation. Reading flow: Control flow is straightforward and exception messages are informative, but inconsistent naming and documentation force readers to reconcile the stated intent with the implementation.
Run 3
Code Structure: Three small, logically separated methods provide good organization. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: The main weakness is misleading naming: validateBalance checks for timeouts, while validateMessage and validateSession create exceptions. Parameter names such as defaultOrder and currentBatch obscure their controller-related meaning, and Javadoc parameter names do not match the signatures. Code length: Methods are concise, although else blocks after returns are unnecessary. Action granularity: Most lines perform one action, but inline null checks combine conditions and returns. Reading flow: Straightforward branching and explicit exception messages help comprehension, but inconsistent terminology and tightly grouped imports interrupt an otherwise natural flow.