Fix feature matcher when feature throws
While working on #294 I noticed that FeatureMatcher#featureValueOf may throw.
Right now, that may happen in:
- HasToString, if the actual object has a custom toString method which throws
- FileMatchers.aFileWithCanonicalPath and siblings
I'm gonna squash as soon as you review.
Thanks for contributing. I disagree with this one because if there's an exception at this level, then it's not a mismatch, but something is deeply broken and we should stop immediately.
Well, for the toString method, you have a point. But we can't say that in general. Look at FileMatchers#aFileWithCanonicalPath: actualFile.getCanonicalPath() may throw IOException, which totally depends on the actual value. There's nothing deeply broken here.
I would argue that that is different, because it reports a known possible failure that is in the domain of the matcher. For generic feature matchers, it's harder to make universal decisions. If you wanted to enforce consistency, I'd rather remove the exception handling from the file matcher.
What does the additional complexity handling of the exception do to improve the user's experience?
I would argue that that is different, because it reports a known possible failure that is in the domain of the matcher.
This is really where we disagree. I believe it's a "user space" issue, instead. Not a Matcher problem.
It's the same concept as throwing in matchesSafely() if the method for matching throws. We don't do that, of course. We try-catch and return false. See e.g. HasProperty
@alb-i986 please can you rebase from master, as hamcrest-core and hamcrest-library have been refactored a lot and also deprecated, so that everything is just in hamcrest.
Rebased and squashed. Ready to be merged.
Going to try and kick start hamcrest, so if you want to get it merged, please rebase from the branch v2.3-candidates.
Still trying to understand how has permissions to perform a release.