pow() does not throw error for extra or incorrect arguments like quotient() does

[thadguidry]

To Reproduce

Steps to reproduce the behavior:

1. Open Expression Editor on existing project
2. On any column use Custom Text Transform with value.pow(2,8)
3. Notice the preview result of null
4. Change the expression to value.quotient(2,8)
5. Notice the preview result of Error: quotient expects two numbers

Current Results

null is shown in preview result, instead of an error (since value is passed as one of the arguments with additional 2 arguments (2,8) supplied)

Expected Behavior

pow() should check arguments like quotient() does and show similar error.

Screenshots

Versions

• Operating System: Windows 10
• Browser Version: Firefox latest
• JRE or JDK Version: JDK8
• OpenRefine: openrefine-3.4-beta-458-g109aa78

Datasets

Additional context

[chetan-v]

I did something for it. @thadguidry please check.

[thadguidry]

@tfmorris or @wetneb will check (they are 2 of our core developers) as I'm staying out of active development. But I will be happy to test once merged.

[wetneb]

What do you intend to compute with value.pow(2,8)?
If you want to compute 2*2*2*2*2*2*2*2 (aka 256), then you should just use pow(2,8), not value.pow(2, 8). Same for quotient.

[thadguidry]

@wetneb Oh you are absolutely right! Hmm, we should give warnings then. Perhaps I should change this issue title and comment? Or close this and open a new one might be best.

[chetan-v]

Hi @thadguidry
I use only pow(,8) and they give null.
I see the function that only return null not any exception.
main/src/com/google/refine/expr/functions/math/Pow.java
Which is in this file.
I add that line from function of call of quotient.java file that show this Error: quotient expects two numbers .

[tfmorris]

What do you intend to compute with value.pow(2,8)?
If you want to compute 2*2*2*2*2*2*2*2 (aka 256), then you should just use pow(2,8), not value.pow(2, 8). Same for quotient.

Yes, it's an error, but I think the point of the original bug report was that the error handling for the two cases should be equivalent. They should either both return error or both return null. I have a strong preference for the former.

This isn't limited to pow(). All of these functions are exempt from the test for too many arguments:

OpenRefine/main/tests/server/src/com/google/refine/grel/FunctionTests.java

Lines 133 to 137 in c8a721a

	// Not sure which, if any, of these are intended, but fixing them may break existing scripts
	Set<String> returnsNull = new HashSet<>(Arrays.asList("chomp", "contains", "coalesce", "escape", "unescape",
	"exp", "fingerprint", "get", "now", "parseJson", "partition", "pow", "rpartition",
	"slice", "substring", // synonyms for Slice
	"unicode", "unicodeType"

"chomp", "contains", "coalesce", "escape", "unescape", "exp", "fingerprint", "get", "now", "parseJson", "partition", "pow", "rpartition", "slice", "substring", "unicode", "unicodeType"

[elroykanye]

This isn't limited to pow(). All of these functions are exempt from the test for too many arguments:

OpenRefine/main/tests/server/src/com/google/refine/grel/FunctionTests.java

Lines 133 to 137 in c8a721a

	// Not sure which, if any, of these are intended, but fixing them may break existing scripts
	Set<String> returnsNull = new HashSet<>(Arrays.asList("chomp", "contains", "coalesce", "escape", "unescape",
	"exp", "fingerprint", "get", "now", "parseJson", "partition", "pow", "rpartition",
	"slice", "substring", // synonyms for Slice
	"unicode", "unicodeType"

"chomp", "contains", "coalesce", "escape", "unescape", "exp", "fingerprint", "get", "now", "parseJson", "partition", "pow", "rpartition", "slice", "substring", "unicode", "unicodeType"

Would we then have to modify every single one of these?

[antoine2711]

Would we then have to modify every single one of these?

Yes @elroykanye. It's the same pattern to use to check.
(It's possible some might have been fixed with other issues, but unlikely.)

Regards,
Antoine