[
https://issues.apache.org/jira/browse/GROOVY-10856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-10856:
---------------------------------
Description:
if you have a method which takes certain parameters, and annotate it
{{@NamedVariant}}, and then try a {{respondsTo}} with a null, or an empty
array, you get this exception, listing both the methods that are there, rather
than the expected groovy-falsehood (empty list) for no matching methods.
This is related to
# GROOVY-8248
# GROOVY-8660
but is different in scope because this is about the behaviour, specifically, of
MetaObjectProtocol::respondsTo, which states clearly in the documentation that:
{quote}This method is "safe" in that it will always return a value and never
throw an exception
{quote}
... which turns out not to be true, and should be. The behaviour may not be
wrong for the calls described in the other two bugs, but
{{MetaObjectProtocol::respondsTo}}, specifically, should be catching this, and
returning, as promised, a groovy falsehood. (probably an empty list, which is
correct as neither of the methods match.)
Attached, a small script demonstrating this, which shows the problem clearly if
simply run in groovy console.
{code:groovy}
import groovy.transform.*
@NamedVariant
def myMethod(int number, String name) {
println "number: ${number}; name: ${name}"
}
println myMethod(42, 'Arthur')
println myMethod(name: 'Arthur', number: 42)
def result1 = respondsTo('myMethod', 42, 'Arthur')
println "positive match: ${result1}"
def result2 = respondsTo('myMethod', [number: 42, name: 'Arthur'])
println "positive match: ${result2}"
def result3 = respondsTo('myMethod', null)
// expected an empty list, a groovy-falsehood
{code}
was:
if you have a method which takes certain parameters, and annotate it
{{{}@NamedVariant{}}}, and then try a respondsTo with a null, or an empty
array, you get this exception, listing both the methods that are there, rather
than the expected groovy-falsehood (empty list) for no matching methods.
This is related to
# GROOVY-8248
# GROOVY-8660
but is different in scope because this is about the behaviour, specifically, of
MetaObjectProtocol::respondsTo, which states clearly in the documentation that:
{quote}This method is "safe" in that it will always return a value and never
throw an exception
{quote}
... which turns out not to be true, and should be. The behaviour may not be
wrong for the calls described in the other two bugs, but
MetaObjectProtocol::respondsTo, specifically, should be catching this, and
returning, as promised, a groovy falsehood. (probably an empty list, which is
correct as neither of the methods match.)
Attached, a small script demonstrating this, which shows the problem clearly if
simply run in groovy console.
> MethodSelectionException when calling respondsTo()
> --------------------------------------------------
>
> Key: GROOVY-10856
> URL: https://issues.apache.org/jira/browse/GROOVY-10856
> Project: Groovy
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 4.0.6
> Environment: Seen in Groovy 4.0.6 on Linux x64 with java 17.0.5 and
> MacOS aarch64 in Java 19.0.1. I don't think any of that is significant. 😀
> Reporter: Rachel Greenham
> Priority: Minor
> Attachments: responds-to-issue.groovy
>
>
> if you have a method which takes certain parameters, and annotate it
> {{@NamedVariant}}, and then try a {{respondsTo}} with a null, or an empty
> array, you get this exception, listing both the methods that are there,
> rather than the expected groovy-falsehood (empty list) for no matching
> methods.
> This is related to
> # GROOVY-8248
> # GROOVY-8660
> but is different in scope because this is about the behaviour, specifically,
> of MetaObjectProtocol::respondsTo, which states clearly in the documentation
> that:
> {quote}This method is "safe" in that it will always return a value and never
> throw an exception
> {quote}
> ... which turns out not to be true, and should be. The behaviour may not be
> wrong for the calls described in the other two bugs, but
> {{MetaObjectProtocol::respondsTo}}, specifically, should be catching this,
> and returning, as promised, a groovy falsehood. (probably an empty list,
> which is correct as neither of the methods match.)
> Attached, a small script demonstrating this, which shows the problem clearly
> if simply run in groovy console.
> {code:groovy}
> import groovy.transform.*
> @NamedVariant
> def myMethod(int number, String name) {
> println "number: ${number}; name: ${name}"
> }
> println myMethod(42, 'Arthur')
> println myMethod(name: 'Arthur', number: 42)
> def result1 = respondsTo('myMethod', 42, 'Arthur')
> println "positive match: ${result1}"
> def result2 = respondsTo('myMethod', [number: 42, name: 'Arthur'])
> println "positive match: ${result2}"
> def result3 = respondsTo('myMethod', null)
> // expected an empty list, a groovy-falsehood
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
