Unclear error message when MethodNotFound

[ciaranmcnulty]

Currently when Prophecy\Exception\Doubler\MethodNotFoundException is thrown the message and exception includes the class of the double, not the interface or class being doubled.

This leads to messages like:

 method `Double\Person\P1::getName()` is not defined.

When it would be clearer for users to have something like:

 method `\Person::getName()` is not defined.

[ciaranmcnulty]

I'm interested in catching and handling this error inside PhpSpec, but don't currently have a way to get the class/interface on which the method should be defined.

[ciaranmcnulty]

Oh and anecdotally, this is something that is difficult for new learners; they find the message hard to interpret.

[everzet]

Care to PR?

[ciaranmcnulty]

It's on my list but thought I'd report first in case someone could pick it up :-)

[flohw]

I encounter a similar problem recently. Let me know if I should create another issue.

When I mock a class but make a typo on the full class name (namespace and class name) then call my method to mock on my ObjectProphecy I get the same exception (MethodNotFoundException). I think it should throw another one like ClassNotFoundException before the MethodNotFoundException. The error could be understood more quickly.

[nickedwards]

@flohw I just had this issue too. Scratching my head for a minute there, and this pointed me in the right direction, so thanks!

I agree that in this instance it should throw something like ClassNotFoundException instead. MethodNotFoundException didn't really make sense in that situation. However, I guess thats a minor issue.

[jon-acker]

This is certainly a head-scratcher for newbies - has anyone picked it up? If not I can give it a go.

[joachim-n]

I've had a poke around at this but I'm stumped.

At the point where the exception is thrown, we have access to the ObjectProphecy, but AFAICT to get from that the name of the class or interface for the prophecy would require getting them from its $lazyDouble property, which isn't accessible.

Would be useful to get some direction from maintainers on how to get this to work.

My first idea would be to implement __toString() on ObjectProphecy to output a human-friendly string representation of the prophecy for general debugging use.

[stof]

Rather than __toString (which will enable casting to string in any context, which might lead to weird issue), I'd rather add a getter returning the expected class name