Robe may throw exception if a gem overrides `Class#instance_methods`

[aifreedom]

Robe may throw exception if a gem overrides `Class#instance_methods`

[dgutov]

Hi!

I looked into this case and it seems that it's because exifr overrides Class#instance_methods to include additional entries in the return of instance_methods but didn't include that in instance_method.

That sounds like a bug: it violates the contract of those methods, seems like. Have you tried reporting it?

My proposed solution to this is to rescue NameError for the candidates mod.instance_method(sym).

I'm not sure it's the right approach: if the methods we call are allowed to do whatever (and essentially, they do), then rescuing NameError may not be enough as well. instance_method may raise a different error, or instance_methods may start raising errors or return unexpected values.

Maybe that calls for a circumvention of said override, like we do for a few methods already: 9a33e54

But I still have a question about why EXIFR::JPEG is scanned when scanning candidates for an instance of a totally unrelated class.

Because Robe performs almost no type inference, and when it does not know the type, it scans all classes and modules. It's explained in README.md.

[aifreedom]

Hi Dmitry, thanks for the prompt reply! I agree that this is a bug in that gem. I'll report it to them.

I'm not sure if my approach is the right one. But I think that rope shouldn't be broken when scanning a gem with bug. Using begin ... rescue ... end is one way to protect rope from being affected. There might be better ways to do it of course. I'm not familiar enough with robe's code. Do you have better ways to make it more robust?

[dgutov]

I'll report it to them.

Let me know how it goes.

There might be better ways to do it of course. I'm not familiar enough with robe's code.

Have you looked at the linked commit?

[ypresto]

I have same issue on EXIFR::JPEG

[dgutov]

Ok, let's try the workaround.

[ypresto]

Now works well, thanks!!!