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() { }
@Override
public Throwable fillInStackTrace() {
// 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) {
return ThrowableUtil.unknownStackTrace(new StacklessClosedChannelException(), clazz, method);
} }
Run 1
The code is generally readable with clear purpose. The class has a single responsibility and uses flat structure with minimal nesting. The Javadoc and method names clearly communicate intent. However, readability is slightly reduced by inconsistent formatting: the class declaration line mixes annotations, modifiers, and field declarations without proper line breaks, and the private constructor's empty body is awkwardly placed. The fillInStackTrace method is concise but its comment could be clearer. Overall, the code is concise and maintains good action granularity, but the formatting inconsistencies prevent a higher score.
Run 2
The code is mostly readable but has some structural issues. The class purpose is clear - a stackless ClosedChannelException optimization. The Javadoc and method names convey intent well. However, the class declaration is compressed onto a single line with annotations and fields, making it harder to scan. The constructor placement on the same line as the field declaration violates convention. The fillInStackTrace method is concise and its purpose is evident, though it could be a one-liner. The newInstance method is straightforward and readable. Overall, the code is functional and understandable but would benefit from better formatting with proper line breaks and separation of declarations, which would improve its readability score to around 16-17.
Run 3
The code is logically organized but suffers from formatting issues that hurt readability. The class-level Javadoc and @UnstableApi annotation are on the same line as the class declaration, making the header difficult to parse. Constructors, methods, and fields are not consistently spaced. Nesting is nonexistent (good), and intent is mostly clear from the Javadoc. However, the compact formatting reduces clarity. Each action is on its own line, which helps, but the overall reading flow is disrupted by inconsistent whitespace and the merged Javadoc/class line. The code is concise, but conciseness here comes at the cost of visual separation. With proper formatting, it would likely score 15-16, but as presented, it is harder to scan quickly.
Run 1
Code Structure: The class has a logical arrangement of fields, constructor, override, and factory method, but compressed formatting obscures these boundaries. Nesting: Minimal nesting makes the logic easy to follow. Clarity of intent: Descriptive names and documentation clearly explain stack-trace suppression and exception creation. Code length: The implementation is concise without unnecessary logic. Action granularity: Statements are simple, but the annotation, class declaration, field, and constructor share a line, reducing visual separation. Reading flow: Inconsistent line breaks and closing braces attached to statements interrupt otherwise natural top-to-bottom reading.
Run 2
Code Structure: The small class logically groups its field, constructor, override, and factory method, but compressed formatting obscures these boundaries. Nesting: Minimal nesting makes the implementation easy to follow. Clarity of intent: Descriptive names and documentation clearly explain the stackless exception and factory behavior. Code length: Concise and free of unnecessary logic, although excessive compression reduces readability. Action granularity: Most executable lines contain a single action, but the annotation, class declaration, field, and constructor share one line; closing braces also share lines with statements. Reading flow: The member order is natural, but inconsistent line breaks, missing visual separation after the package declaration, and inline closing braces interrupt scanning.
Run 3
Code Structure: The class logically groups its field, constructor, override, and factory method, but compressed formatting obscures these boundaries. Nesting: Minimal nesting makes the implementation easy to follow. Clarity of intent: Descriptive names and documentation clearly explain the stackless exception and factory behavior. Code length: The implementation is appropriately concise, with no unnecessary logic. Action granularity: Several declarations and closing braces share lines, reducing visual separation despite simple individual operations. Reading flow: The overall sequence is natural, but placing the annotation, class declaration, field, and constructor on one line, along with inconsistent brace placement, interrupts scanning.