> For Gradle and Spock ther is an easy solution to this. Write a method like
> callGroovyMethodThatThrowsDeclaredCheckedException that delcares the exception,
> is written in Groovy and that does the Closure call for you. The Groovy method will
> unwrap the Exception for you automatically.
This isn't really feasible for Gradle, which has hundreds of such invocations, plus many more in user-provided plugins. Most people aren't aware of this problem, so they will just call the closure straight away.
> Then there is the problem with catching undelcared checked Exceptions in Java. If the method does not say that is an throwing such an Exception, then what do you do?
I think the current behavior is optimizing for the wrong case. I rarely see code calling a closure (which could do anything) and then acting on a specific exception, but I regularly see code that unwraps InvokerInvocationException. (By the way, you could always catch Exception or Throwable and then do further checks, very similar to how InvokerInvocationException needs to be handled.) Also the behavior for closures is different from the behavior for methods without throws-clause, which do not wrap checked exceptions.
> There might be people depening on the InvokerInvocationException, so there is potential for a breaking change.
My hope was that the current behavior would be considered a clear bug (maybe introduced only recently), but if it has always been this way, it's probably yet another item to put on the 2.0 list. I agree that it would be a fairly big breaking change.