Print a message if the benchmark operation fails #286
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This gives us a chance to at least print the name of the failure exception, because the exception can be lost if any of the tear-down methods in the finally blocks throws an exception. An alternative would be to complicate the exception handling even more to make sure the original exception does not get lost, but at that point, the benchmark is doomed anyway.
This may help avoid interleaving the contents of stderr and stdout.
|
The other commit could help with #192. |
farquet
approved these changes
Jul 3, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This gives us a chance to at least print the name of the failure exception, because the exception can be lost if any of the tear-down methods in the finally blocks throws an exception.
This can actually occur in some of the Spark benchmarks because they try to dump the result of the last operation but do not expect the very first operation to fail. This assumption has been proven wrong #283 and losing the original exception makes things a bit more confusing. A fix for that is in #288.
An alternative would be to complicate the exception handling to make sure the original exception does not get lost even though the benchmark is already doomed at that point.