Thanks for the suggestion.
The only extra information it adds is it designates that the exception happened in the reflectively called method rather than in the reflective engine itself. In practice, the distinction is very subtle, and I doubt it is worth keeping InvocationTargetException.
I agree that distinction is subtle, but stack traces are only intended for programmers working on the Checker Framework, when the Checker Framework crashes. Therefore, I don't think that exposing the subtlety is necessarily a problem, if that information might be useful.
The error message provides one more useful piece of information beyond what you mentioned. It gives the arguments to the call (this is the
Arrays.toString(args) part of the message). In this particular example, this part of the information is not very informative (it is
[org.checkerframework.checker.nullness.KeyForSubchecker]), but in other cases we have found it helpful, and that's why it is in the message.
By the way, I completely agree with issue #3700: The Checker Framework should produce a useful error message rather than crashing.