Source code
package org.junit.internal.runners.statements;
import java.util.ArrayList;
import java.util.List;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.MultipleFailureException;
import org.junit.runners.model.Statement;
public class RunAfters extends Statement {
private final Statement fNext;
private final Object fTarget;
private final List<FrameworkMethod> fAfters;
public RunAfters(Statement next, List<FrameworkMethod> afters, Object target) {
fNext = next;
fAfters = afters;
fTarget = target;
}
@Override
public void evaluate() throws Throwable {
List<Throwable> errors = new ArrayList<Throwable>();
try {
fNext.evaluate();
} catch (Throwable e) {
errors.add(e);
} finally {
for (FrameworkMethod each : fAfters) {
try {
each.invokeExplosively(fTarget);
} catch (Throwable e) {
errors.add(e);
}
}
}
MultipleFailureException.assertEmpty(errors);
}
}
Run 1
The code is well-structured and readable. It follows a clear logical flow: try to execute the next statement, collect any exceptions, run after methods in finally, then assert no errors occurred. Nesting is minimal with only two levels (try-finally and for-loop with try-catch). The intent is clear from class and method names (RunAfters, evaluate, fNext, fAfters). Variable names use a somewhat cryptic 'f' prefix convention but are otherwise descriptive. Each line generally handles one action, and the reading flow progresses naturally from setup through execution to cleanup and validation. The use of MultipleFailureException.assertEmpty is concise and clear. Minor improvements could include removing the 'f' prefix or adding brief comments, but overall this is clean, maintainable test infrastructure code.
Run 2
The code is well-structured with clear separation of concerns. The class has a single responsibility - running after-methods - and uses logical field names (fNext, fTarget, fAfters) consistent with JUnit conventions. The evaluate() method is flat with only two levels of nesting (try-catch and for loop). Action granularity is good: each statement performs one logical operation. The reading flow follows the natural execution order: create errors list, execute next statement, collect errors, then run afters, finally assert no errors. The only slight drawbacks are the single-letter variable name 'e' (common for exceptions but less descriptive) and the lack of comments explaining the error collection strategy. The method length is appropriate (15 lines), and the code avoids unnecessary complexity. Overall, highly readable with minor room for improvement.
Run 3
The code is highly readable due to its clear structure, flat nesting, and concise implementation. The class has a single responsibility: running after-methods after a statement. Field names use a consistent prefix ('f') convention, and the constructor is straightforward. The evaluate() method follows a logical flow: execute the next statement, collect failures, run all after-methods in a finally block, then assert no failures occurred. Nesting is minimal (only one level inside loops/catch blocks), and each line performs a single action. Intent is evident from class and method names. The only minor drawbacks are the use of abbreviated field names (fNext, fTarget, fAfters) which may require familiarity with JUnit's internal conventions, and the slightly terse exception handling pattern. Overall, the code is nearly ideal in readability.
Run 1
Code Structure: Fields, constructor, and evaluation logic are logically organized, with failure aggregation handled consistently. Nesting: The try/finally, loop, and inner try/catch introduce moderate nesting, but it is justified by cleanup requirements. Clarity of intent: The code clearly runs the next statement, executes all after-methods regardless of failure, and reports collected errors; legacy f-prefixed fields and the generic variable name each slightly reduce clarity. Code length: Concise, with no unnecessary logic or repetition beyond essential exception handling. Action granularity: Each statement performs one clear action. Reading flow: Execution proceeds naturally from the main statement through cleanup to final failure reporting.
Run 2
Code Structure: Fields, constructor, and evaluation logic are logically organized, with failure collection handled consistently. Nesting: The try/catch/finally containing a loop and another try/catch adds moderate nesting, but it is justified by cleanup requirements. Clarity of intent: The code clearly runs the next statement, executes all after-methods even on failure, and reports collected errors; legacy f-prefixed fields and the generic variable name 'each' slightly reduce clarity. Code length: Compact and purposeful, with no unnecessary logic. Action granularity: Each statement performs one action, making execution easy to follow. Reading flow: Initialization, primary execution, cleanup, and failure reporting form a natural sequence.
Run 3
Code Structure: Fields, constructor, and execution method are logically organized, with failure collection handled consistently. Nesting: The try/finally, loop, and inner try/catch introduce moderate nesting, but it is justified by cleanup requirements. Clarity of intent: The code clearly runs the primary statement, executes all after-methods regardless of failure, and reports accumulated errors; legacy f-prefixed fields and the generic name 'each' slightly reduce clarity. Code length: Compact without unnecessary logic or repetition. Action granularity: Each line performs a single clear action. Reading flow: Execution proceeds naturally from the primary statement through cleanup to final error reporting, although understanding the final assertion depends on familiarity with MultipleFailureException.