Exception assertions are surprisingly not-fluent

[zack-sampson]

Basically a decade-later followup to: #219

In this issue, the reporter requests support for expressions like this:

assertThatThrownBy((()->myMethodThatThrows()).isInstanceOf(NullPointerException.class);

But the answer was basically just "invoke assertThrows and then use Truth on the exception it returns." which is awkward and not fluent:

assertWithMessage("our exception message is right")
    .that(
        assertThrows(IllegalArgumentException.class, MyCoolClass::myCoolLambda)
    .hasSubjectThat()
    .contains("error")

looks worse to me than something like:

assertWithMessage("our exception message is right")
    .that(MyCoolClass::myCoolLambda)
    .throwsException(IllegalArgument.class)
    .withMessageContaining("error");

the current solution uses nesting and two assertion libraries instead of fluent chaining and one. And that's surely worse, right? am I trippin?

[cpovirk]

It is still something that we have in the backs of our minds, and it comes to the forefront again each time we come with a new idea for a feature Truth could provide or encounter a new sharp edge in assertThrows. But as that suggests, we've found that it's a surprisingly big design space, and we'd want to make sure to get it right in a compelling enough way that it justifies training users to use the Truth API over assertThrows or Kotlin's assertFailsWith.

We have #621 open. It's titled in a way that suggests that it's basically about providing our own identical copy of assertThrows, but I've been treating it as a more general bug for an improved API for catching thrown exceptions in preparation for Truth assertions, so we can discuss things like this there.