TypeSafeMatcher should not return false if null or wrong type is passed about javahamcrest

[sf105]

I think you're missing the point here. Matchers just tell us whether an argument matches given criteria, not whether there's a bug in the code being tested. It's up to the caller of the matcher to decide what to do with the information. Also, matchers might be called repeatedly against multiple arguments to find the one that's right.

In this case, the criteria include that the argument is of a given type.

[snellm]

Perhaps, and I think your argument is stronger for test code, but not when Hamcrest is used in production code.

I could post examples of production bugs in a system we're both familiar with which are due to developers thinking TypeSafeMatcher is a matcher which adds runtime type safety to Matcher, which it doesn't - in fact it makes runtime code less type safe since it obscures cases where the wrong type is passed by assuming that false should be returned. It might be clearer if it was called "TypeCheckingMatcher"?

[sf105]

you're probably right that it's misnamed, but it's hard to fix that now. The current contract of a matchers is that it will not explode but just return true or false. If you need something else, then you might be better off to fork your own version.

[snellm]

We will patch locally, and in the longer term look at migrating at least our production code off Hamcrest.

PS Here's a example of the sort of bug we've found - this has been present in the codebase since 2009, but nobody has noticed that the assert can never fail, despite this helper method being used in many tests:

    public void assertDoesNotContains(Class... classes) {
        List<Class> listofClasses = getListOfClasses();
        for (Class aClass : classes) {
            assertThat(listofClasses, not(Matchers.typeCompatibleWith(aClass)));
        }
    }