This repository has been archived by the owner on Nov 30, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Give correct error message for
expect {}.not_to raise_error(/foo/)
#1456Give correct error message for
expect {}.not_to raise_error(/foo/)
#1456Changes from all commits
b98096c
ee27f82
7df981b
c08a500
32ea28c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any change in behaviour?
Is looks like that previously a regexp would have been used as an exception?
This change indeed seems the right thing to do. I’m wondering, why it worked the same way before?
Is it because we still were tolerant to whatever it is an exception or something matcheable with a string message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So.. there is a change in "behavior", but it pretty much just affects what failure messages come out. These two ivars are really only used for that purpose, and aren't exposed externally, thankfully; the only impact I can find is that a slightly wrong failure message gets generated (it acts as though you supplied an exception if you supplied only a regex). Could have had larger impact, but the main place we look at the
@expected_error
, we only check@expected_error != Exception
, which is not true for Regexps either (though I suppose if you suppliedto raise_error(Exception, /foo/)
, you might also be able to get some wrong behavior?).And the reason the specs didn't mind was just that the case checking this had a test that only checked the part of the failure message the outcomes had in common ("risks false positives"), which was still being produced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to dissect it. Before the change, this was printing a slightly different warning:
and now it's a more appropriate for
not_to raise_error(/regexp/)
:My apologies that it took that long to figure out.