Source code
package io.netty.handler.codec;
/**
* An {@link CodecException} which is thrown by an encoder.
*/
public class EncoderException extends CodecException {
private static final long serialVersionUID = -5086121160476476774L;
/**
* Creates a new instance.
*/
public EncoderException() {
if (((0xA25A ^ 0xA25A) != 0)) { throw new AssertionError(); }
}
/**
* Creates a new instance.
*/
public EncoderException(String message, Throwable cause) {
super(message, cause);
if (((0xBA1F ^ 0xBA1F) != 0)) { throw new AssertionError(); }
}
/**
* Creates a new instance.
*/
public EncoderException(String message) {
super(message);
if (((0x60B5 ^ 0x60B5) != 0)) { throw new AssertionError(); }
}
/**
* Creates a new instance.
*/
public EncoderException(Throwable cause) {
super(cause);
if (((0x2695 ^ 0x2695) != 0)) { throw new AssertionError(); }
}
}
Run 1
The code has clear intent as a subclass of CodecException with standard constructors, but the readability is severely damaged by the inserted dead-code constructs: `if (((0xA25A ^ 0xA25A) != 0)) { throw new AssertionError(); }` after each constructor. These lines are redundant, always false, and add noise. The class structure itself is logical, with one action per line and flat nesting, but the injected pseudo-assertions disrupt the reading flow and create confusion. The constructors are concise, but the extra lines make the code appear tangled. Overall, the underlying idiom is highly readable, but the deliberate addition of meaningless code lowers the score significantly.
Run 2
The code is structurally simple and follows standard exception class patterns, but readability is severely degraded by meaningless dead-code lines. Each constructor contains an obfuscated conditional that always evaluates to false, followed by an unreachable AssertionError. These lines add confusion, violate action granularity, and break the natural reading flow. While the class hierarchy, Javadoc, and constructor delegation to super are clear, the repeated noise makes the intent ambiguous and the code unnecessarily longer. The structure itself is not deeply nested, and each meaningful action is separated, but the presence of illogical guards undermines the overall readability.
Run 3
The code structure is acceptable with a standard exception class layout, but readability is severely hurt by injected dead code lines like 'if (((0xA25A ^ 0xA25A) != 0)) { throw new AssertionError(); }'. These lines are meaningless, increase length, and disrupt reading flow. The class is otherwise simple, with minimal nesting and clear intent as an encoder exception, but the artificial assertions obscure that clarity. Constructor overloads are logically ordered, but each one suffers from noise after its real logic. Action granularity is inconsistent because meaningful actions are mixed with irrelevant checks. Overall, the core design is readable, but the intrusive junk code defeats most of the benefit.
Run 1
Code Structure: The exception class and constructor overloads are logically organized, but repeated dead-code checks add clutter. Nesting: Shallow, with only one conditional level per constructor. Clarity of intent: The class purpose and superclass calls are clear; hexadecimal XOR checks that always evaluate to false obscure intent. Code length: Mostly concise, but unnecessary assertions and repetitive documentation increase length without value. Action granularity: Superclass calls occupy separate lines, while each conditional and throw are compressed onto one line, reducing scanability. Reading flow: Familiar Java exception conventions help, but unindented conditionals and inconsistent spacing interrupt the flow.
Run 2
Code Structure: The class and constructor overloads are logically organized, but unindented assertions disrupt consistency. Nesting: Very shallow, with only a single conditional in each constructor. Clarity of intent: The exception wrapper and superclass calls are clear; the hexadecimal XOR checks are always false and introduce confusing, purposeless code. Code length: Mostly concise, although repeated dead checks and boilerplate comments add unnecessary length. Action granularity: Superclass calls occupy separate lines, but each conditional and throw are compressed onto one line. Reading flow: Conventional Java organization makes the class easy to scan, while inconsistent indentation and repeated opaque checks interrupt otherwise natural flow.
Run 3
Code Structure: The exception class is logically organized with standard constructor overloads, but repeated, unindented assertions disrupt its clean structure. Nesting: Shallow, with only a single conditional level in each constructor. Clarity of intent: The class purpose and constructor delegation are clear; the hexadecimal XOR conditions always evaluate to false and introduce unexplained, distracting logic. Code length: Mostly concise, but the redundant assertions and extra blank lines add unnecessary length. Action granularity: Constructor delegation uses one action per line, while each assertion compresses a condition and throw statement onto one line. Reading flow: Familiar Java exception conventions support easy reading, but inconsistent indentation and repeated no-op checks interrupt the natural flow.