Handling of StoppedByUserException will correctly stop execution in case of any additional errors coming from @AfterClass methods or class rules.

[ghost]

Due to #1125.

Several points:

1. Original code did not notify listeners about StoppedByUserException. I took the same approach for handling this exception with other execution errors - StoppedByUserException will not be delivered to listeners while all other errors will. Though I think listeners should get notification about reason of execution interruption.
2. Method for unpacking all exceptions looks a little bit helpful and at the moment the same logic is used in EachTestNotifier. I was thinking about moving that method to MultipleFailureException class to make it common and allow usage of one in different places (e.g. writers of custom runners can get benefit from one), but in that case method will become a part of the public API, and I'm not sure that JUnit needs that.
3. I don't like methods' names, but was unable to find something more appropriate.

[kcooney]

Why was the catch block for StoppedByUserException removed?

[ghost]

Now StoppedByUserException is handled in the processExecutionFailures() method, despite single or multiple exceptions came from evaluating class block statement.

[ghost]

Closing this pull request since original fix was not accepted. Discussion with kcooney helped to figure out better approach to fix the issue.

@kcooney I believe it will be more appropriate if JUnit team will fix this issue when #1118 will be merged successfully.

[kcooney]

@NarendraPathai good point about tests throwing StoppedByUserException directly. I don't see a reason why someone would have a test do that, but if they did, failing the test is the most reasonable thing to do.

Perhaps it's best if we don't worry about listeners being notified too often (or not often enough) of the StoppedByUserException. The listeners that are tracking the pass/fail status of tests should "notice" that some tests weren't run, and presumably the user would know why.

I hope I didn't push you away with all of the comments. There is no one correct solution to this, and making changes to the core of JUnit without adversely affecting existing code is tricky.

Note that the majority of changes to JUnit aren't made by the JUnit team. The JUnit team reviews changes, do merges, update release notes and do releases, but most functional changes are from contributors like you. If you want to take another stab at this after #1118 is merged, please feel free.

[ghost]

Sure, I understand. From my point of view, I just think that person who has suggested better approach is the first candidate to implement that approach :-) And if you will not be able to do that, then someone else will be.

[kcooney]

I think it depends on how difficult it is to implement the "better" approach, how much time everyone has, and how important the feature or fix is.