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

Add support to test caught exceptions #591

Closed
cpollet opened this issue May 1, 2021 · 3 comments · Fixed by #813
Closed

Add support to test caught exceptions #591

cpollet opened this issue May 1, 2021 · 3 comments · Fixed by #813

Comments

@cpollet
Copy link

cpollet commented May 1, 2021

I would like to be able to assert that some method calls are wrapped in a try/catch block catching certain type of exceptions.

Typical use case would be to make sure that runtime WebApplicationExceptions are caught when calling a remote resource using JAX-RS.

I'd be happy to try to contribute with a PR, if it could eventually be merged.

@hankem
Copy link
Member

hankem commented May 1, 2021

ArchUnit currently does not recognize

the bytecode signature of try/catch blocks,

For a simple example

    try {
        RemoteService.method();
    } catch (WebApplicationException e) {
        e.printStackTrace();
    }

the byte code looks like this (see also JVM Spec §3.12):

   0: invokestatic  #2      // Method RemoteService.method:()V
   3: goto          11
   6: astore_1
   7: aload_1
   8: invokevirtual #4      // Method javax/ws/rs/WebApplicationException.printStackTrace:()V
  11: return
Exception table:
   from    to  target type
       0     3     6   Class javax/ws/rs/WebApplicationException
Try-with-resources statements are even more complex.

For example,

    try (RemoteService remoteService = new RemoteService()) {
        remoteService.method();
    } catch (WebApplicationException e) {
        e.printStackTrace();
    }

compiles to the following byte code:

   0: new           #2      // class RemoteService
   3: dup
   4: invokespecial #3      // Method RemoteService."<init>":()V
   7: astore_1
   8: aload_1
   9: invokevirtual #4      // Method RemoteService.method:()V
  12: aload_1
  13: invokevirtual #5      // Method RemoteService.close:()V
  16: goto          35
  19: astore_2
  20: aload_1
  21: invokevirtual #5      // Method RemoteService.close:()V
  24: goto          33
  27: astore_3
  28: aload_2
  29: aload_3
  30: invokevirtual #7      // Method java/lang/Throwable.addSuppressed:(Ljava/lang/Throwable;)V
  33: aload_2
  34: athrow
  35: goto          43
  38: astore_1
  39: aload_1
  40: invokevirtual #9      // Method javax/ws/rs/WebApplicationException.printStackTrace:()V
  43: return
Exception table:
   from    to  target type
       8    12    19   Class java/lang/Throwable
      20    24    27   Class java/lang/Throwable
       0    35    38   Class javax/ws/rs/WebApplicationException

but ASM offers MethodVisitor.html.visitTryCatchBlock, which could be implemented in ArchUnit's MethodProcessor.

How would you want to make the information available in ArchUnit's domain objects?
Should JavaCall have something like Set<JavaClass> getCaughtExceptions()?

@codecholeric
Copy link
Collaborator

This might be a nice addition, but I would propose a type CaughtException or sth. like that (similar to InstanceOfCheck) that can offer you type and source code location (and possibly more info in the future).

crizzis added a commit to crizzis/ArchUnit that referenced this issue Feb 25, 2022
crizzis added a commit to crizzis/ArchUnit that referenced this issue Feb 25, 2022
@crizzis
Copy link
Contributor

crizzis commented Feb 25, 2022

PR attached.

(Sorry if sth is not quite done the 'ArchUnit way', but this is my first PR here)

crizzis added a commit to crizzis/ArchUnit that referenced this issue Feb 25, 2022
codecholeric pushed a commit to crizzis/ArchUnit that referenced this issue Mar 27, 2022
codecholeric added a commit that referenced this issue May 29, 2022
This will add `TryCatchBlocks` to the ArchUnit core and introduce `JavaCodeUnit.getTryCatchBlocks()` to examine try-catch blocks that have been parsed from the bytecode of a method or constructor. We also add an extension `JavaAccess.getContainingTryBlocks()` to make it easy to verify that certain accesses in code are wrapped into certain try-catch blocks (e.g. "whenever method x is called there should be a try-catch block to handle exception case y").

Resolves: #591

Signed-off-by: Krzysztof Sierszeń <[email protected]>
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.

4 participants