assertj: Assertions.assertThatThrownBy doesn't support the as/describedAs API

This:

    Assertions.assertThatThrownBy(something::call)
        .as("This is not OK")
        .isInstanceOf(expectedException);

yields the default message:

    java.lang.AssertionError: Expecting code to raise a throwable.

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 20 (10 by maintainers)

Most upvoted comments

I can agree with calling hasBeenThrown() in AbstractThrowableAssert.

We can’t rename assertThatCode as it would be a breaking change, I’m a bit reluctant to add assertThatCall as an alias assertThatCode because users might wonder what is the difference with assertThatCode.

joel-costigliola on Oct 11, 2017

Documented.

joel-costigliola on Oct 31, 2015

Yes, I (finally!) see the problem. assertThatThrownBy asserts not null on the throwable before any chained calls, as or otherwise. I suppose this was made so users can check whether the call through anything at all… I admit that I have indeed used this a couple of times.

The only solution I see is that we use assertThatCode. However, the message in case of throwable being null should be fixed.

The fix: All public methods in AbstractThrowableAssert which check parts of the throwable (isSameAs, isInstanceOf, hasMessage, …) should first call hasBeenThrown().

There is no point in checking a throwable which is null because this is de-facto usage of a part of the AbstractObjectAssert API not intended for throwables. A null throwable is already an error, not a regular value which should be checked.

And I would prefer the method assertThatCode be called assertThatCall since that’s more specific and after all, its argument is called ...Callable.

mbjelac on Oct 11, 2017