Make various classes catch Exception instead of RuntimeException even when only RuntimeException is theoretically possible.
#6859
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
![copybara-service[bot]](https://avatars.githubusercontent.com/in/44061?s=60&v=4){kind=small}
…even when only `RuntimeException` is theoretically possible. In fact, because checked exceptions are a Java-source-language feature (rather than a JVM feature), it's possible to throw them when you're not "supposed to," either through tricky Java code or more naturally through other languages, such as Kotlin. We have seen this happening a few times in tests. This causes exceptions to slip past the `catch` blocks that are meant to handle them. This could cause operations to hang, such as when one listener of a `ListenableFuture` throws an exception, preventing subsequent listeners (such as a listener that powers `Futures.transform`) from running. I didn't cover _every_ `catch (RuntimeException ...)` block in our codebase, but I tried to get the ones that looked most likely to be affected. RELNOTES=Changed various classes to catch `Exception` instead of `RuntimeException` even when only `RuntimeException` is theoretically possible. PiperOrigin-RevId: 587705182
copybara-service
bot
changed the title
Exception instead of RuntimeException even when only RuntimeException is theoretically possible.
copybara-service
bot
force-pushed
the
test_587705182
branch
from
fedb419
to
a1efb43
Compare
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.
Make various classes catch
Exceptioninstead ofRuntimeExceptioneven when onlyRuntimeExceptionis theoretically possible.In fact, because checked exceptions are a Java-source-language feature (rather than a JVM feature), it's possible to throw them when you're not "supposed to," either through tricky Java code or more naturally through other languages, such as Kotlin.
We have seen this happening a few times in tests. This causes exceptions to slip past the
catchblocks that are meant to handle them. This could cause operations to hang, such as when one listener of aListenableFuturethrows an exception, preventing subsequent listeners (such as a listener that powersFutures.transform) from running.I didn't cover every
catch (RuntimeException ...)block in our codebase, but I tried to get the ones that looked most likely to be affected.RELNOTES=Changed various classes to catch
Exceptioninstead ofRuntimeExceptioneven when onlyRuntimeExceptionis theoretically possible.