Introduce extension APIs to handle exceptions from lifecycle callback methods

[pietrygamat]

Overview

This change is an alternative take on issue #1454 based on still not merged PR #1509. In this version there are separate interfaces supporting exception handling in each of @BeforeAll, @BeforeEach, @AfterEach and @AfterAll, so that it is not forced on the handler to implement handleTestExecutionException in addition to handle(Before/After)(/All/Each)ExecutionException

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes
• All continuous integration builds pass

[marcphilipp]

@JockX Thanks for the PR! We'll discuss it in the next team meeting this Friday.

[marcphilipp]

Team Decision: Please put all of the new methods into a single LifecycleMethodExecutionExceptionHandler interface, rename the methods to handle[...]MethodExecutionException (add Method), make them default methods with empty implementations, and throw them into the kitchen sink.

[marcphilipp]

@JockX Thanks for updating the PR! Please run ./gradlew spotlessApply to fix the build.

[pietrygamat]

@marcphilipp I would appreciate some help regarding the failure in azure tests. Does not seem to be related to the changes introduced in this PR

[marcphilipp]

No, that's related to me merging #1885, I'm afraid. I'll try to fix it ASAP.

[marcphilipp]

@JockX It's fixed in master now. Please rebase once again.

[marcphilipp]

Thanks for rebasing! This looks very promising!

[sormuras]

Looks good to me.

Especially the LifecycleMethodExecutionExceptionHandlersTests class. 👍

[sbrannen]

Thanks for all of the work on this PR.

I think this is good enough to be merged into master now. The implementation looks solid, and we can polish documentation, etc. after the merge.

@JockX, can you please provide the source for the PNG you have supplied?

There are some inconsistencies in the image, and it would be great if anyone in the community can update the image.

Also, please rebase on the current master and resolve conflicts. The PR should then be ready to merge.

[sbrannen]

Actually, I'll see if I can merge this PR and resolve the conflicts myself.

So, please hold off on making any further changes at this time.

[sbrannen]

This has been merged into master in 2844ee4.

However, @JockX, it would be great if you could provide the source for the PNG you supplied.

Thanks in advance!

[pietrygamat]

@sbrannen, the png is a screenshot of a word document I created to more or less mimic the original. Should I put it in the repo? How is this usually handled?

[sbrannen]

@sbrannen, the png is a screenshot of a word document I created to more or less mimic the original. Should I put it in the repo?

Yes, that would be great! 👍

How is this usually handled?

Funny you should ask... for this particular graphic, the original author lost the original source, meaning we've had no way to edit it. So now that you have a "source", we would be very grateful to gain access to it. 😉

[sbrannen]

Note that this PR was further refined in 8aaac85.