Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #260: Fix IllegalArgumentException with GlobalVar taking a single argument #261

Conversation

Alex-Vol-SV
Copy link
Contributor

When calling a GlovalVar declared to accept one argument and the caller
passes null to the function it yields an IllegalArgumentException
instead of passing the null argument. This is unique to single argument
method calls and appears rooted in the way Grrovy lang handles the
invocation when null is provided.

This fix was inspired from the code in the invoked Groovy methods.

@Alex-Vol-SV Alex-Vol-SV changed the title Issue #260: Fix IllegalArgumentException with GrobalVar taking a single argument Issue #260: Fix IllegalArgumentException with GlobalVar taking a single argument Aug 12, 2020
When calling a Gloval Var declared to accept one argument and the caller
passes null to the function it yields an IllegalArgumentException
instead of passing the null argument. This is unique to single argument
method calls and appears rooted in the way Groovy lang handles the
invocation when null is provided.

This fix was inspired from the code in the invoked Groovy methods.
@Alex-Vol-SV Alex-Vol-SV force-pushed the fix-illegal-argument-exception-with-one-null-argument branch from 7d4fa5c to 58b1bf9 Compare August 12, 2020 15:11
Comment on lines +457 to +466
{ args ->
// When calling a one argument method with a null argument the
// Groovy doMethodInvoke appears to incorrectly assume a zero
// argument call signature for the method yielding an IllegalArgumentException
if (args == null && m.getNativeParameterTypes().size() == 1) {
m.doMethodInvoke(e.value, MetaClassHelper.ARRAY_WITH_NULL)
} else {
m.doMethodInvoke(e.value, args)
}
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
{ args ->
// When calling a one argument method with a null argument the
// Groovy doMethodInvoke appears to incorrectly assume a zero
// argument call signature for the method yielding an IllegalArgumentException
if (args == null && m.getNativeParameterTypes().size() == 1) {
m.doMethodInvoke(e.value, MetaClassHelper.ARRAY_WITH_NULL)
} else {
m.doMethodInvoke(e.value, args)
}
})
{ args -> m.doMethodInvoke(e.value, args ?: MetaClassHelper.ARRAY_WITH_NULL) })

The Elvis operator is a bit more succinct here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not believe it is for all use cases. The additional check for number of parameters is needed. args may be null for a zero argument method call.

Copy link
Contributor

@nre-ableton nre-ableton Aug 12, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see. Shouldn't it be m.getNativeParameterTypes().size() > 0 then?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion this code in Groovy is incorrectly handling the null case
invoked Groovy

The line in question should assign EMPTY_ARRAY to the null argumentArray and allow the subsequent lines decide if ARRAY_WITH_NULL is instead appropriate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, more than one null arguments would have manifested as array of null. I can add additional tests for the behavior with multiple arguments but I believe the null single argument is an edge case not handled properly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I'm a bit unfamiliar with the background of the original failure here. I need to sit down and read through the linked issue before approving this PR. However, if another maintainer sees that everything is alright, I'm fine with them merging this (hence my leaving neutral feedback and not "requested changes").

Copy link
Contributor

@nre-ableton nre-ableton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a few minor suggestions, otherwise LGTM.

Edit: I need to sit down and read through the background of this issue a bit before being able to add a qualified +1 review.

Taking one line improvement

Co-authored-by: Nik Reiman <[email protected]>
Copy link
Contributor

@nre-ableton nre-ableton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants