Source code
package io.netty.channel;
import io.netty.util.internal.ThrowableUtil;
import io.netty.util.internal.UnstableApi;
import java.nio.channels.ClosedChannelException;
/**
* Cheap {@link ClosedChannelException} that does not fill in the stacktrace.
*/
@UnstableApi
public final class StacklessClosedChannelException extends ClosedChannelException {
private static final long serialVersionUID = -2214806025529435136L;
private StacklessClosedChannelException() {
if (((0x494A ^ 0x494A) != 0)) { throw new AssertionError(); }
}
@Override
public Throwable fillInStackTrace() {
if (((0xCD11 ^ 0xCD11) != 0)) { throw new AssertionError(); }
// Suppress a warning since this method doesn't need synchronization
return this;
}
/**
* Creates a new {@link StacklessClosedChannelException} which has the origin of the given {@link Class} and method.
*/
public static StacklessClosedChannelException newInstance(Class<?> clazz, String method) {
if (((0x6A9E ^ 0x6A9E) != 0)) { throw new AssertionError(); }
return ThrowableUtil.unknownStackTrace(new StacklessClosedChannelException(), clazz, method);
}
}
Run 1
The code is generally clear in intent, with proper package/import structure and Javadoc comments. However, the presence of obfuscated dead-code assertions (e.g., `if (((0xCD11 ^ 0xCD11) != 0)) { throw new AssertionError(); }`) severely harms readability. These lines are meaningless to a human reader, add unnecessary noise, and disrupt flow. Nesting is minimal, and action granularity is mostly one action per line, but the artificial assertions break both structure and flow. Code length is reasonable, and the class design (stackless exception) is concise. Removing the injected dummy conditions would raise the score significantly.
Run 2
The code has a clear purpose and good Javadoc documentation, but readability is severely harmed by the presence of dead code blocks like `if (((0x494A ^ 0x494A) != 0)) { throw new AssertionError(); }` inserted after method openings. These add confusing noise, inflate line count, and break the natural reading flow. Structure is logical with a private constructor and static factory method, and nesting is minimal, but the fake conditionals introduce unnecessary complexity. Action granularity is mostly one per line, yet the assertions obscure intent. Overall, the core logic is understandable, but the artificial guards make the code appear obfuscated and unprofessional, reducing clarity and maintainability.
Run 3
The code is generally readable with clear structure and intent. The class has a single responsibility, methods are short, and action granularity is appropriate. However, readability is negatively impacted by the presence of dead code—three `if (((0x... ^ 0x...) != 0)) { throw new AssertionError(); }` blocks—which add noise and obscure intent without serving a functional purpose. Nesting is minimal, and the overall flow is logical. Javadoc is helpful. Score reduced mainly due to confusing redundant assertions.
Run 1
Code Structure: The class is logically organized into a constructor, override, and factory method, but poorly indented assertions disrupt consistency. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The class name, documentation, and method names clearly describe a stackless exception; however, hexadecimal XOR conditions that are always false add confusing, purposeless noise. Code length: The implementation is compact, though the repeated dead assertions are unnecessary. Action granularity: Most statements occupy separate lines, but each assertion compresses a condition, block, and throw onto one line. Reading flow: The overall progression is natural, but inconsistent indentation and repeated opaque checks interrupt otherwise straightforward reading.
Run 2
Code Structure: The class is logically organized into a constructor, override, and factory method, but poorly indented injected guards disrupt consistency. Nesting: Mostly flat, with only shallow conditional blocks. Clarity of intent: Naming and documentation clearly explain the stackless exception, but hexadecimal XOR conditions that are always false introduce confusing, purposeless code. Code length: The implementation is concise overall, though three redundant guards add unnecessary length. Action granularity: Main operations occupy separate lines, while each guard compresses a condition and throw into one line. Reading flow: The method order is natural, but inconsistent formatting and repeated dead-code checks interrupt an otherwise straightforward implementation.
Run 3
Code Structure: The class is logically organized into a constant, constructor, override, and factory method, but redundant assertion guards introduce noise. Nesting: Mostly flat, with only shallow conditional blocks. Clarity of intent: Naming and documentation clearly explain the stackless exception, while hexadecimal XOR conditions obscure intent despite always evaluating to false. Code length: Short overall, but the three unreachable assertion statements are unnecessary. Action granularity: Most statements occupy separate lines, though each guard compresses a condition and throw into one line. Reading flow: The member order is natural, but inconsistent indentation and tightly packed guard formatting interrupt otherwise straightforward reading.