Allow to create that type of assertions:
by chaining on the error instance, not on the function that throw an error
Coverage remained the same when pulling c32ae3e on vbardales:master into 0e560c6 on chaijs:master.
return error on throw method to chain on error properties, possibly d…
…ifferent from message
Coverage remained the same when pulling 2bb0ff2 on vbardales:master into 0e560c6 on chaijs:master.
Makes sense to me. @logicalparadox?
This change broke the previous way of doing further tests on the error. And the documentation hasn't been updated.
* Please note that when a throw expectation is negated, it will check each
* parameter independently, starting with error constructor type. The appropriate way
* to check for the existence of a type of error but for a message that does not match
* is to use `and`.
* .and.not.throw(/good function/);