😕 I have many cons:

1. I am a newbie here but even I understand w/o docs that means the No exception! template here.
2. I am not able to remember and type without making mistakes this new template. (I guess two weeks later you will not be able to remember it too)
3. A lot more tests require fixes. You find and fix only the smaller part of the tests. I found about 60 files. (I searched by throw " pattern). There are interesting templates:
   -1. Throw "Previous statement unexpectedly succeeded..."
   -2. throw "Execution should not have reached here"
   -3. throw "Command did not throw exception"
   -4. throw "expect Import-PSSession to throw"
   -5.

    try {
        & $sb
        throw "Expected FullyQualifiedErrorId: $expectedFqeid"
    }
    catch {
        $_.FullyQualifiedErrorId | Should Be $expectedFqeid
    }

It seems the latter is most accurate but somewhat redundant and complex.
I would prefer No exception! or at worst Previous command should be throw!

@lzybkr Any comments?

@iSazonov - @lzybkr and I want a message that is more descriptive and self-documenting for the example. I don't expect the exact message to be reproduced in every test (although it would be nice). As long as the message clearly describes the scenario in the test failure log, then that should be sufficient. As you point out, there are different ways of applying the pattern and scrict adherence to that specific message may not always make sense (as shown in your example 5).

@mirichmo I'm trying to look at things from the other side. Sometimes this is useful. :-)
If the team has already found a more appropriate message, then I have no objections.
Please clarify the file list in the PR is exhaustive? There is a 'copy-paste' problem when someone can take as a template a bad file. It would be good to fix all the files that were found by throw " pattern. Even example 5 seems can be aligned with the template. (If you are busy and I can do it).

I am closing this PR after discussing it with @JamesWTruher. The point of "No Message!" is that it is a terse statement that is self-descriptive and reads well when observed in the Pester results. A more descriptive error message will not add value to the Pester output.

@iSazonov You are welcome to go back and update the rest of the tests to conform to the "No Message!" string if you want to. However, your time and effort could be better spent addressing other issues or adding new features in the code base.

@mirichmo It seems I am somewhat perfectionist. :-) The thought about "No message!" inconsistance is already sitting in my head. If I'll have free time, I'll try to fix these tests. (I think this will save a lot of reviewer's time in future, because people won't copy-past bad files.)

I'd prefer a helper function with a nice name like AssertUnreached or something like that - then it's easy to fix in one place.

Other ways we could improve this - fix Pester, or introduce a "better" helper, maybe it would look something like:

{ Do-Something -ea Stop } | Should Throw { $_.FullyQualifiedErrorId | Should Be Blah }

And if we don't change Pester, it can still look similar

{ Do-Something -ea Stop } | PSShouldThrow { $_.FullyQualifiedErrorId | Should Be Blah }

The point here is - it still looks like Should Throw which is widely understood, but you pass a script block to do the validation on the exception object.

@lzybkr I open Issue pester/Pester#673 And nohwnd suggested that what you are talking about. Also nohwnd said that Paster 4 contains 'Should throw' improvements and will be released soon.
Need a conclusion from PG whether we now have to do something or we will wait Pester 4.

If the new version is portable to .Net Core and Linux, then it would be good to pick it up.