Source code
package org.junit.internal.runners.statements;
import org.junit.internal.AssumptionViolatedException;
import org.junit.runners.model.Statement;
public class ExpectException extends Statement {
private Statement fNext;
private final Class<? extends Throwable> fExpected;
public ExpectException(Statement next, Class<? extends Throwable> expected) {
fNext = next;
fExpected = expected;
}
@Override
public void evaluate() throws Exception {
boolean complete = false;
try {
fNext.evaluate();
complete = true;
} catch (AssumptionViolatedException e) {
throw e;
} catch (Throwable e) {
if (!fExpected.isAssignableFrom(e.getClass())) {
String message = "Unexpected exception, expected<"
+ fExpected.getName() + "> but was<"
+ e.getClass().getName() + ">";
throw new Exception(message, e);
}
}
if (complete) {
throw new AssertionError("Expected exception: "
+ fExpected.getName());
}
}
}
Run 1
The code is well-structured with clear separation of concerns, a single-purpose class, and a logical evaluate() method. Nesting is minimal (one try/catch block) and action granularity is good, with most lines performing one task. The intent is clear: expect a specific exception or fail. However, the reading flow is slightly disrupted by the boolean 'complete' flag and the post-try conditional, which forces the reader to track state across the method. Field names like 'fNext' and 'fExpected' are outdated and reduce clarity compared to modern Java conventions. The code is concise but could be improved with a more natural control flow (e.g., using a local variable to capture the outcome). Overall, it is readable but not exemplary.
Run 2
The code is well-structured and readable. It has a clear purpose: verify that an expected exception is thrown. The class is focused with a single responsibility, and the evaluate method follows a straightforward try-catch flow with minimal nesting. Variable names like fNext and fExpected are slightly archaic (Hungarian notation prefix 'f' for field), but they are used consistently. The logic is easy to follow: run the next statement, if it completes without exception, fail; if an unexpected exception is thrown, wrap it; if the expected exception type is thrown, silently succeed. The message construction is somewhat verbose but clear. Overall, the code is concise and maintains good reading flow, though modern Java conventions would drop the 'f' prefix and use final fields with 'next' and 'expected'.
Run 3
The code is generally clear and well-structured. It follows a logical try-catch flow and keeps nesting shallow. Each action is on its own line, which improves readability. The intent is mostly clear: fail if no exception is thrown or if the wrong type is thrown, and rethrow assumption violations. However, the boolean flag 'complete' adds slight ambiguity and control-flow complexity. Variable names like fNext and fExpected follow an old-style Hungarian notation that reduces clarity. The use of a generic Exception with a detailed message is reasonable but could be more specific. Overall, the code is readable and concise but could improve with clearer variable names and a more direct way to express the post-try assertion.
Run 1
Code Structure: Fields, constructor, and evaluation logic are logically organized. Nesting: Shallow try/catch blocks with one nested conditional keep complexity low. Clarity of intent: The class clearly verifies an expected exception while preserving assumption violations; however, the complete flag and f-prefixed field names require minor interpretation. Code length: Concise, with no unnecessary duplication. Action granularity: Each statement performs a single action; multiline string concatenation remains readable. Reading flow: Execution proceeds naturally from running the statement to checking exception compatibility and detecting a missing exception, though the flag-based final check adds slight mental overhead.
Run 2
Code Structure: The class cleanly separates initialization from exception-checking behavior. Nesting: A single conditional inside a catch block keeps nesting shallow. Clarity of intent: The class name, expected exception type, and error messages clearly communicate its purpose; prefixed field names and the indirect 'complete' flag slightly reduce clarity. Code length: Compact, with no unnecessary repetition. Action granularity: Each statement performs one distinct action, and multiline message construction remains easy to follow. Reading flow: Execution proceeds naturally from running the wrapped statement to handling exceptions and detecting a missing exception, though understanding the final check requires tracking the flag through the try/catch.
Run 3
Code Structure: The class is logically organized, with fields, constructor, and a focused evaluation method. Nesting: Shallow try/catch blocks and a single nested conditional are easy to follow. Clarity of intent: The class name and expected exception type clearly communicate the purpose, though the f-prefixed fields and 'complete' flag are slightly less descriptive. Code length: Compact without unnecessary repetition. Action granularity: Each statement performs one clear action; multiline string concatenation remains readable. Reading flow: Execution, exception handling, and the missing-exception assertion follow naturally. The completion flag requires a little mental tracking, but overall readability is high.