See the commit description, this is a really annoying side effect which has led to bad code making it through the tests, and then failing in real conditions.
setExpectedException should not catch exceptions coming from PHPUnit'…
…s error handler
Too often tests are believed to work because they catch an Exception, while they are in fact just catching a PHP warning/notice/error that has been converted to an Exception by PHPUnit
Closed by 4ad409a.
This change is problematic. Now one can't write a simple test case for PHP core functions (like DateTime) that throw plain old Exceptions. Let alone, this change breaks BC, so now existing code out there that did $this->setExpectedException('Exception'); no longer works and we all have to rewrite the tests with try/catch blocks.
Agreed... this commit was not thought out very well. And it doesn't make any sense in relation to the problem it allegedly solves. When I explictly say I am expecting an Exception to be thrown, I'm expecting just that: an Exception to be thrown. This shouldn't catch an ErrorException, an Extended_Exception, or anything else. So I don't see the issue. (I am guessing PHPUnit is not throwing plain Exceptions when it catches things like syntax/runtime errors.)
Not to mention this is blatantly counterintuitive. And not mentioned anywhere in the documentation.
You are beating a dead horse. Expecting the generic Exception class is possible again in the master branch (which will become PHPUnit 3.7). That does not mean, however, that using the generic Exception class in your code is suddenly a good idea.
Any chance that this fix of the fix gets into the next 3.6.x release?
@lathspell You could always use the Standard PHP Library Exceptions if you think writing exception classes is overkill. They're all allowed by PHPUnit, even pre-3.7.