elefevre/elements-of-unit-testing-style — pull request #2 by FredrikWendt (2013-08-20 19:47:48+00:00)
Title: added note about the risk of using @expected

I have seen test suites (classes) where all the @expected annotations mistakenly caught an exception that was thrown by some setup code, and was introduced after the test suite was written. The effect was that a tester reported a bug with a clear stack trace and everything, and some junior programmer didn't understand what was happening since all unit tests that should've caught the issue were all passing.
We rewrote the tests to explicitly show what line should the the expected exception, and then all tests failed and she could go about fixing the bug.

I have myself ended up in this situation while TDD:ing code, and since then I realized that while using try catch is more verbose, it's also explicit and I think that is a good trait of a test. There's really only one statement that should throw an exception, but when using the @expected annotation, we're really saying that "any statement in this method invocation may throw this Exception, and when it happens, all is fine, regardless of where it was thrown".