Stefano Cordio

Hopefully, 661e5d5245ab6f6372022cd34e4b280cc5d46577 fixes the issue with pitest. BTW, thanks for your patience, @groov1kk! We will review your PR as soon as we can.

To be checked how this PR overlaps with #2433.

@weiyilei please get familiar with [git rebase](https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase) operations. Although we are happy to support contributors, a preliminary understanding of common git commands is expected. Your favorite IDE might also help...

> Slightly off topic, I think the existing `assertThatCode` is not great as it exposes throwable assertions, even if the code throws one, it does not read very nicely Yes,...

@joel-costigliola I went with `ThrowingExecutableAssert`, maybe clearer than just `ThrowingAssert` and harder to be confused with `ThrowableAssert`. Could you have a look and let me know what you think? I'd...

With the new assertion hierarchy (`ThrowingExecutableAssert` / `AbstractThrowingExecutableAssert`), a new `assumeThatCode(Callable)` cannot be easily added as all the code around Byte Buddy supports only `AbstractAssert` types. We might add it...

I'm not sure I understand where the problem is. Would you mind providing a reproducible example?

@HeZean sorry, this is not yet up for grabs, I suggest keeping an eye on the [good first issues](https://github.com/assertj/assertj-core/labels/good%20first%20issue).

[`SQLException`](https://docs.oracle.com/javase/7/docs/api/java/sql/SQLException.html) implements `Iterable`, that's why it's considered ambiguous. As you already figured it out, the workaround is to qualify the call with a cast or a variable. We might consider...

**Team decision**: let's add `assertThat(SQLException)` / `assumeThat(SQLException)` and the corresponding BDD variants. Implementation notes: * In order to properly support the existing subtypes of `SQLException`, the signature should be: ```java...