Does this affect the script functionality?
The removed line belongs to an empty closure.
By default a closure in groovy will return the last evaluation, so an empty closure it is exactly the same (irellevant) as a simple return line, from the compiler point of view. Its just a void execution.
@jim.sears Like @anon46315158 has pointed out, if there’s nothing else to that code (stuff you haven’t shown) then that if block does nothing (apart from wast a little time on the processor).
Are you saying that if I leave it blank that the script will exit and not execute the remaining code?
I didn’t see it exit when I wrote the script the first time and that is why I added it, but I’ll go back and revisit if you tell me it should exit as desired.
One other thing, I thought the return was in an empty closure meaning it was the only line in the closure.
{ return }.
Is that what you mean when you said, “the removed line should be in an empty closure”?
@anon46315158
I realize you are trying to help and I appreciate that but I take offense to “test is not relevant”. The test is relevant to me and my test objectives.
Futher more, why should the purpose of my code be the center of this issue when the problem is with how Katalon executes the formatter?
If you are ofended is your problem, was not my intention.
I am just pointing that testing engine formatter with invalid/ irrelevant code snippets it is useless, at least for me.
In such case, either putting a newline before the last expression, or explicitly using return may yield better readability.
I, for myself, sometimes use the return keyword, sometimes not, it’s often a matter of taste. But often, inside of closure, we omit it more often than not, for example. So even if the keyword is optional, this is by no means mandatory to not use it if you think it halters the readability of your code.
This only proves my point that I can choose to use it or not. There is not hard and fast rule for coding style. If Katalon interferes with what is acceptable coding then the bug again lies with the formatter. And it isn’t an invalid piece of code per that link.
If you are asking what the return value is supposed to be then I would say there is no value. I merely want to exit the test if the condition fails. I find the code easier to read than wrapping the entire test in a if/else.
Again, we are talking about the test objective and test script instead of the formatter. The issue is the formatter is changing my code and it shouldn’t, right? Isn’t the formatter where the bug exists, changing code it should be?
Note that i am not mentioning yet that you are using the return keyword inside an if codelock, which makes it invlaid from the start… You are confusing the return keyword in groovy with the pass keyword in python.
Your code it is not valid from the begining
You already answered to your ‘bug report’. The rest is just noise.
Your actual bug is not a bug in given conditions. Feel free to extend your research with a valid code snippet an maybe then somebody will take it seriously
@Russ_Thomas - after a ‘noisy’ conversation with bionel that didn’t move the needle, I need to ask this to be bug. I included my code as an example and it has become the focus. I feel the the issue is the formatter taking action to modify my code and I don’t understand why removing the ‘return’ is acceptable. Do you care to address why this isn’t a bug on the formatter?
It might seem that way, but @anon46315158 is right about the code. And he is, in his own way, trying to point you in the right direction…
Regarding the formatter, I suspect there is a rule somewhere that says something like:
Remove unnecessary return (checkbox)
I suspect that rule is checked on.
Sorry, I remain to be convinced this is a bug. If I find time, I’ll dig through the settings and see if I can find it. If there isn’t a setting, that could be argued to be a bug.
Provided will break valid codes, sure. It is definetly a bug. At this moment for me is a feature
And no, i wont digg into it more… Unless i will be really really bored one day…
