Yes, reporting the incomplete auxclasspath (or even the missing classes) would be nice.
I think, this would be part of #194

However, I did a quick try, and we could already add config errors like this:

RuleContext context = (RuleContext) data;
context.getReport().addConfigError(new ConfigurationError(this, "missing class/method.."));

It would be then for now just in this rule, that we would report this, but it would be a start...
With #194, we could add a convenience method in AbstractRule (similar to addViolation) and also add support for asserting such config errors in the test framework.
We probably need a different data structure though, in order to avoid reporting the same missing class multiple times...

Yes, that is part of #194.

The hard part however is telling the user which classes are missing, so they can easily fix it. For ClassNotFoundException that is very straightforward. For these exceptions however, we don't really know...

Also of note, we should avoid duplicate reports to avoid being noisy, so on this case we would have to know we reported the issue on a static and thread-safe manner (to avoid issues on multi-threaded analysis).

I feel that's way beyond the scope of this PR, and definitely part of a larger task as described by #194

Yes, the "full" solution will definitely be #194 with a separate PR.
Do you think, just adding a "log.warn" with "incomplete auxclasspath" would be too noisy already (since we don't have de-duplication...)?
For detecting the actual missing class - in this concrete example, the missing/invalid classes are related to exploredType - so we could report this class and the exception message (which hopefully gives a hint, which class exactly was missing).

Considering how we systematically find people complaining about warn logs they can't get rid of (Gradle users mostly), I'd be hesitant on doing that...

We would have to be very careful with the wording... the missing class is related to exploredType (used in one of the declared methods in this case), but it's definitely not exploredType itself...