NullPointerException when using argThat() for long parameter in verify about mockito

[mockitoguy]

I agree that better error message would be great. Do you have suggestions how to implement it?

There's a 'longThat' method that can be used in this context.

Hope that helps!

[pettermahlen]

Is that longThat method different from the one I mentioned in the bug report? I've been able to solve my problem (IIRC, I used the longThat(Matcher<Long>) version), so the point of this report is to help prevent others from running into the same issue.

I don't have any suggestions for how to implement it - the stack trace confuses me a lot and I wouldn't know where to start looking for the problem. Do you have any pointers where to start? I'm completely unfamiliar with the Mockito source unfortunately..

[mockitoguy]

Thanks for reporting the issue! It is very useful to build this documentation.

I'm not sure if it is feasible to improve the error message in this case. E.g. the implementation of argThat() does not know the receiver object nor the method. I used to think that this is not possible. However, your initial report got me thinking. Perhaps we can inspect the generic type of the matcher and if it is a primitive wrapper, it can return 0 or false. We would really appreciate your contribution :)

You could start with a failing test case (you have it already) and try to add some smartness to the implementation of argThat method.

[bric3]

Perhaps we can inspect the generic type of the matcher and if it is a primitive wrapper, it can return 0 or false.

That is probably feasible, but this won't be of any use in most cases, because most of us use existing matchers where most are generic with an Object upper bound.

[mockitoguy]

Yeah, it would be good. Who wants to contribute the fix?

On Fri, Apr 3, 2015, 07:35 Brice Dutheil [email protected] wrote:

Perhaps we can inspect the generic type of the matcher and if it is a
primitive wrapper, it can return 0 or false.

That is probably feasible, but this won't be of any use in most cases,
because most of us use existing matchers where most are generic with an
Object upper bound.

Reply to this email directly or view it on GitHub
#117 (comment).

[TimvdLippe]

Is this still an ongoing issue? I am willing to do some investigation on this one.

[TimvdLippe]

I did some investigation and the problem is at the GenericTypeExtractor.
When executing the posted testcase, the Matcher that is created is IsEqual.
When executing getActualTypeArguments() on BaseMatchers.class, it returns Type[] {TypeVariableImpl} with name T, as BaseMatchers is the declared superclass of IsEqual.

This behaviour is because IsEqual is declared as generic with <T>. Therefore I sadly don't see a feasible solution and would alter the documentation to state that primitives should use the other methods such as longThat(long).

[mockitoguy]

Ah, I had high hopes for the type extracting :(. Looks like the argXxx methods need to be included in MockitoHamcrest. Do you want to contribute?

[TimvdLippe]

I can contribute yes (but have a lot of PRs open already, might cause some flooding). But what do you mean with argXXX?

Do you mean a signature like public static long argThat(Matcher<Long> matcher)? I am not sure if it compiles but I can try it out.

Still I don't think the underlying issue is solved, because IsEqual<T> with T=Long will not match the Matcher<Long>, but that would be left for experimentation.

[ChristianSchwarz]

Do you mean a signature like public static long argThat(Matcher matcher)? I am not sure if it compiles but I can try it out.

It doesn't compile, argThat(Matcher<Long>) has the same erasure as argThat(Matcher<T>). I guess this issue can't be fixed.
The workaround is to use MockitoHamcrest.longThat(Matcher<Long>) or better Mockito.eq(long).

IMO this issue can be closed.

[bric3]

I agree, maybe with future JDK version we could do something, not right now. Thanks @ChristianSchwarz for this archeological dive in mockito issues ;)

[bric3]

Also remove bug label, because it's not really a bug in mockito.

[ChristianSchwarz]

@bric3 Please reopen.

It doesn't compile, argThat(Matcher) has the same erasure as argThat(Matcher). I guess this issue can't be fixed.

I was wrong. After looking #246 I noticed that this issue can be fixed! Two methods don't have the same erasure if the return type is different. The java 8 compiler generates a warning in this case, don't know about other versions. We need to provide overloads for all primitives like this:

public static long argThat(Matcher<Long> matcher) {
        reportMatcher(matcher);
        return 0;
}

For the provided test case the expected MockitoException "Wanted but not invoked ..." is thrown.

[bric3]

@ChristianSchwarz nope that doesn't work, while java byte code allows to have method based on the complete signature (ie name, arg types and return type), the compiler just look at the name and arg types.

The following code don't compile :

long argThat(Matcher<Long> matcher) {}
int argThat(Matcher<Integer> matcher) {}

[ChristianSchwarz]

@bric3
Crazy the JDT compiler has no problem with your sample, it even works at runtime. After some investigation I found this answer on stackoverflow . It should worked with javac too worked until Java 7, as the JLS seems to allow it due to a hole in the specs (if i understand that correct).

Also interesting: With generics, the return type is part of the method signature..

But I agree, keep it closed for now.

[bric3]

This hack does not work with Java 8.

[ChristianSchwarz]

Jup!

It's a bug in eclipse JDT that only occures with a non standard JRE execution environment and compiler compliance setup. I filed an issue for the JDT-Team: Bug 499817

[bric3]

Again, something against Eclipse. It's not the first bad bug using Eclipse compiler.

-- Brice

On Wed, Aug 17, 2016 at 12:39 PM +0200, "Christian Schwarz" [email protected] wrote:

Jup!

It's a bug in eclipse JDT that only occures with a non standard JRE execution environment and compiler compliance setup. I filed an issue for the JDT-Team: Bug 499817

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.