@nitram84 thanks! Looks good, although I will need some time to review this PR, couple days I hope 🙂

What is better unneeded throws declarations or possible decompilation issues?

Hm, it is still unclear for me why rethrow Throwable from catch don't need throws, but throw new Throwable() require throws statement. Maybe it will be not hard to check if throw instruction arg is assigned in catch, I will check this.
Anyway, sure "unneeded throws declarations" is better than decompilation issues.

the common "base" of ClassNode/ClspClass and MethodNode/ClspMethod

Well there is common IMethodDetails which is implemented by MethodNode and ClspMethod.
But for classes it is harder to made similar, because ClspClass is 'unresolved' and have only ArgType, even parents is just array and not a tree like in ClassNode.
But sure, we can add common interface for just some common properties.
Also, some common methods already collected in TypeUtils and MethodUtils. Perhaps TypeUtils.visitSuperTypes will be useful for traversing parents in common way.

classes are objects, should be a logical ArgType.ObjectType

Not sure what you mean, ArgType.ObjectType already here:

Thank you! This is not an easy PR. Take any time you need for a review.

I think found the answer for the special case: https://stackoverflow.com/questions/24981736/why-is-throwing-a-checked-exception-type-allowed-in-this-case

void test1() { // no throws required
	try {
	} catch (Throwable t) {
		throw t;
	}
}
	
void test2() throws Throwable {
	try {
	} catch (Throwable t) {
		Throwable t2 = t;
		throw t2;
	}
} 

This seems to be a Java 7 feature: if a caught exception is directly rethrown, it is not necessary to add a throws declaration for a more general exception type.

At the moment I don't throw exceptions of a try block, if they are handled in catch clause. To fix this I have to remember all thrown exceptions of a try block. For each catch clause I have to check whether an exception is directly rethrown. If yes I have to declare all remembered exceptions of the corresponding try block as thrown. Otherwise I have to declare all thrown exceptions of the catch clause.

Nested try catch blocks might be interesting. There might be more fun with early Java 6 apps that don't support that language feature if someone wants to recompile them with Java 6.

With my "logical ArgType.ObjectType" I just mean that both types ClassNode and ClspClass have the implicit information of representing a type that inherits from Object. So e.g. the OverrideMethodVisitor could be improved by adding override annotations for overridden methods of Object and even if the class hierarchy is incomplete.

I reviewed code and have two news:

1. Good one: instead of going through parent classes to check base exception class, we can use ClspGraph.isImplements method, it was created just for that and heavily used in type inference. And as soon as ClspGraph merged with app classes, this method can be used for all classes.
   So I refactor your PR to use that method and it works fine. Also, I added a check for rethrow Throwable and it also works fine if arg used directly from catch.
2. Bad one: as I mentioned in [core] Missing and invalid throws declarations #2441 (comment) only first level of dependant classes are loaded, so if your instructions traversal method go deeper, method might not have basic blocks loaded and current implementation will just ignore that.
   I will try to create a test case for that, maybe it is not so bad like I think (decompilation batches pack all dependant classes close to each other for processing), but anyway it will be nice to fix this somehow.

Ok, I think it is fine to merge this PR. Processing issue is still there, but to resolving it, will require to apply current instruction checks using low-level code scanner, and that might be hard.