Description

This is pretty minor. It might also be by design.

Basically, if you use ThrowExactly in an AssertionScope, it generates a second message that has the "wrong" context name. (This is apparent for me since I'm trying to work around strange context names in custom assertions, but actually, it's possible you consider the regular way this works to be intended not sure.)

Reproduction Steps

// Arrange
var a = () => { };

// Act

// Assert
using AssertionScope scope = new();
a.Should().ThrowExactly<InvalidOperationException>();

Expected behavior

Should (and does) output this:

Expected System.InvalidOperationException, but no exception was thrown.

Actual behavior

Outputs this instead:

Expected System.InvalidOperationException, but no exception was thrown.
Expected a to be System.InvalidOperationException, but found <null>.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

You probably already know but it seems to be from this line in ThrowExactly:

exception.Should().BeOfType(expectedType, because, becauseArgs);

I think because it is in an AssertionScope this check adds the additional message when the previous one already failed. This is maybe ok, except that because of the way AssertionScopes work, the context name is wrong (sort of).

In a different example:

using AssertionScope scope = new();
value.Invoking(x => x.DoSomething()).Should().ThrowExactly<InvalidOperationException>();

you get the message:

Expected System.InvalidOperationException, but no exception was thrown.
Expected value.Invoking(x => x.DoSomething()) to be System.InvalidOperationException, but found <null>.

I suppose this could be by design, although the wording is not really correct,

Are you willing to help with a pull-request?

No