-
Notifications
You must be signed in to change notification settings - Fork 93
Fix CatchCauseOnlyRethrows onlyRethrows check for multi catch statements
#355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
timtebeek
merged 3 commits into
openrewrite:main
from
nielsdebruin:multi-catch-only-throws-support
Oct 22, 2024
Merged
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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 file contains hidden or 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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of removing this check, I wonder if we should add an additional check with something like
if (catchType instanceof JavaType.MultiCatch) { ... check if any of the thrown exceptions matches ... }. I'd feel slightly more secure with such an approach then dropping this requirement.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Tim, Thanks for the review! I am not sure how to implement this check....
In the base case e.g.
catch(A ex) {throw ex}type A is assigned toexin the body. Hence we can compare the type of the catch parameterexthat of the body. In the multicatch,catch (A | B ex) {throw ex}bothexin the body and parameter will be assigned typeException, as it is not know if they will be of type A or B. UsingJavaType.MultiCatch.getThrowableTypesI can retrieve the possible types the parameterexcan take, but the I can't compare them with the type ofexin the body as this will still be of typeException.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we can't determine it based on type then maybe in case of a
MultiCatchwe could check whetherexceptionis an identifier and if it is whether it's the same identifier asaCatch.getParameter()?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't that already checked on line 114?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, missed that part! Though checking by name is potentially more dangerous than checking by reference.
Not sure what direction to go here then