Iāve used the return statement with the argument false and it worked as expected. But it results in the warning in the Designer.
Now with OH2.1 it resulted also in the code validation with this message.
Therefor Iāve changed it to āreturnā without argument. The parsers were happy, but the code didnāt work any more. The rule isnāt terminated at this line and later the rule throws a NullPointerException,
So Iāve changed the code again to āreturn falseā and I will accept the warning.
@rlkoshak@sjka do you know of a valid keyword or would it make sense to define an exception for the validator? The command return false seems to do what it is supposed to, without exception or warning.
I donāt have any practical experience with the new validator yet so canāt speak to whether this would still be allowed, but I believe break, contrary to what one would expect, actually exits the rule, not just the current context. But I learned that way back on 1.7, that behavior may be different now. And even then that was me trying to use a break in a lambda, not the main part of the rule.
I personally always structure my rules so there is only one exit (itās the coding standard at my first job and it stuck) so I donāt really have much experience with return statements in rules.
The error implies to me that the rule is treated as a function with no return value. I would try return void to see if that makes the parsers and the code happier. Otherwise living with the warnings or restructuring the roles may be required.
I know what you mean and agree that this is often a good idea. Let me give just one example I ran into the other day.
rule "Entrance door monitoring"
when
Item Entrance_Door changed to OPEN
then
if (Night_State.state == ON) {
// 30 lines of wild code
}
end
Alternative:
if (Night_State.state != ON) break or return
// 30 lines of wild code
Of course in reality this situation can become worse if multiple conditions or multiple steps are involved. Iām sure you can think of similar ones If the alternative is a better solution is pure personal preference Iād say.
if (something) return false - Validator: āVoid functions cannot return a value.ā
if (something) return void - Validator: āVoid functions cannot return a value.ā
if (something) return - Validator: āVoid functions cannot return a value.ā
if (something) break - Validator is please but the rule will yield an error: āAn error occurred during the script execution: The name ābreakā cannot be resolved to an item or type.ā
works like a charm. No error in the designer, and no error when loading the file.
By the way: the validation has not changed at all with the OH 2.1 release. The only new thing is that files which are so broken that the parser cannot make sense of it fully will be ignored completely. Before, those parts that the parser read successfully (including any bogus it came up with) were used anyway.
works like a charm. No error in the designer, and no error when loading the file.
Yes, but there is an error during executing the rule. I tried this before. So this return without any parameter doesn“t work.
An error occured during the script execution: Unhandled parameter types: [null, org.eclipse.xtext.xbase.interpreter.im
pl.DefaultEvaluationContext@cffbf8, org.eclipse.xtext.util.CancelIndicator$1@9e19d9]
Urgh! Now I finally got the problem. Sorry, it took me a time to realizeā¦
Thatās indeed not nice! It looks like an ancient bug in the interpreter to me.
Could you please open an issue in https://github.com/eclipse/smarthome for it?
I installed the last Snapshot and there are some changes.
Now the command return
doesn“t cause an error during the rule execution any longer, but it also doesn“t stop the execution as it should.