-
Notifications
You must be signed in to change notification settings - Fork 306
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
TryCatchBlock in lambda will not be collected #1069
Labels
Comments
Thanks for reporting this! Yes, this seems to be a bug, because the synthetic methods created for lambdas are treated differently. We have to remap the try-blocks from those to the original methods. I'm gonna try to fix this (unless somebody else wants to jump in 😉) |
codecholeric
added a commit
that referenced
this issue
Apr 2, 2023
We need to resolve synthetic origins for try-catch-blocks just like other objects declared in `JavaCodeUnit`, like `JavaAccess` or `InstanceofCheck`. Otherwise, a `TryCatchBlock` declared within a lambda will be imported as being declared within a synthetic method (like `lambda$abc$123`). But we throw out these synthetic methods in the end, because the origins should have been fixed during the import to point to the method declaring the lambda. Thus, before this change we lost all those try-catch-blocks together with these methods. Resolves: #1069 Signed-off-by: Peter Gafert <[email protected]>
codecholeric
added a commit
that referenced
this issue
Apr 9, 2023
We need to resolve synthetic origins for try-catch-blocks just like other objects declared in `JavaCodeUnit`, like `JavaAccess` or `InstanceofCheck`. Otherwise, a `TryCatchBlock` declared within a lambda will be imported as being declared within a synthetic method (like `lambda$abc$123`). But we throw out these synthetic methods in the end, because the origins should have been fixed during the import to point to the method declaring the lambda. Thus, before this change we lost all those try-catch-blocks together with these methods. Resolves: #1069 Signed-off-by: Peter Gafert <[email protected]>
codecholeric
added a commit
that referenced
this issue
Apr 15, 2023
We need to resolve synthetic origins for try-catch-blocks just like other objects declared in `JavaCodeUnit`, like `JavaAccess` or `InstanceofCheck`. Otherwise, a `TryCatchBlock` declared within a lambda will be imported as being declared within a synthetic method (like `lambda$abc$123`). But we throw out these synthetic methods in the end, because the origins should have been fixed during the import to point to the method declaring the lambda. Thus, before this change we lost all those try-catch-blocks together with these methods. Resolves: #1069 Signed-off-by: Peter Gafert <[email protected]>
codecholeric
added a commit
that referenced
this issue
Apr 15, 2023
With #847 we have changed the way lambdas are handled. Before ArchUnit didn't have any special handling for lambdas which lead to synthetic methods (like `lambda$foo$123`) being imported like regular methods and connections like `call() -> doSomething()` in the following example would be lost: ``` void call() { inLambda(() -> doSomething()); } ``` Afterwards we started to eliminate these synthetic methods and attached the call directly to the origin method. However, try-catch-blocks are also associated with methods as their owners and here we forgot to attach them to the correct declaring method. Thus, by throwing out synthetic lambda methods from the import we would completely lose try-catch-blocks declared within lambdas. We now fix this by resolving the correct origin/declaring method for any try-catch-block, even if it's declared within a lambda. Resolves: #1069
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
the second assertion will fail
The text was updated successfully, but these errors were encountered: