Skip to content
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

Closed
demonbug opened this issue Feb 23, 2023 · 1 comment · Fixed by #1096
Closed

TryCatchBlock in lambda will not be collected #1069

demonbug opened this issue Feb 23, 2023 · 1 comment · Fixed by #1096

Comments

@demonbug
Copy link

the second assertion will fail

    @Test
    public void test_trycatch_contract() {
        JavaClasses classes = new ClassFileImporter().importClasses(ClassWithTryCatchInLambda.class);

        List<JavaMethodCall> calls = classes.stream()
            .flatMap(cls -> cls.getMethodCallsFromSelf().stream())
            .filter(call -> "parseDouble".equals(call.getName()))
            .collect(Collectors.toList());
        Assertions.assertFalse(calls.isEmpty());

        List<TryCatchBlock> tryBlocks =
            calls.stream().flatMap(call -> call.getContainingTryBlocks().stream()).collect(Collectors.toList());
        Assertions.assertFalse(tryBlocks.isEmpty());
    }

    private class ClassWithTryCatchInLambda {
        public void testCall() {
            testFunctionInterface(text -> {
                try {
                    Double.parseDouble(text);
                } catch (NumberFormatException e) {
                    e.printStackTrace();
                }
            });
        }

        private void testFunctionInterface(Consumer<String> func) {
            func.accept("123456");
        }
    }
@demonbug demonbug changed the title TryBlocks in lambda will not be collected TryCatchBlock in lambda will not be collected Feb 23, 2023
@codecholeric
Copy link
Collaborator

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
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants