Peter Gafert

No, what I meant is that in the place where you see that an exception is thrown (`MethodProcessor.visitInsn(int opCode)`) you don't see which exception is actually thrown, but only that...

Unfortunately this is not possible at the moment, because nobody ever had a use case for it :thinking: It is easily possible to read the byte code version of the...

I also feel like the only way to really be sure it works with JRE 7 is to test it with JRE 7 :thinking: That's by the way also what...

I could well imagine to add this to ArchUnit (to know which version of byte code was imported seems to be just fair, if we also have things like the...

Sounds like a reasonable addition :smiley: Would be worth it to ponder about the implications if several `@AnalyzeClasses` come together then. I.e. ``` @AnalyzeUi @AnalyzeService class MyGeneralArchRules { @ArchTest static...

Thanks for raising this! :slightly_smiling_face: Yes, I know `JavaClass` might be somewhat misleading, maybe something like `JvmClass` would be more fitting, since it's actually looking at bytecode :wink: Unfortunately I...

I'll leave it open for a little, in hopes that some bytecode guru might magically jump in and give us the right hint :wink: But yeah, if we can't come...

Looks nice, but keep in mind that the list of violations might become quite long obscuring the possible solution :wink: Maybe Rule: ... Possible Solution: ... Current Violations: ... would...

I think that makes sense :+1: But I would propose a new configuration `skipStoreUpdate` then. Obviously the [user guide](https://www.archunit.org/userguide/html/000_Index.html#_freezing_arch_rules) should also be improved a little, because these options seem to...

As @hankem said, some generally useful rules we try to include in the `library` package of ArchUnit itself. Other than that everybody can principally publish best practices for a certain...