Getting MissingMethodExceptionNoStack with value 0 in runIn(seconds, [data:0])

One of my apps can no longer pass 0 value through runIn() data parameters. 1 and above work, but 0 will throw "MissingMethodExceptionNoStack" error message.

As you can see in the logs below, if I set dimVal to 1, the param passes but when set to 0, it doesn't.

I get the same error if I set dimVal to "false", meaning the platform can no longer interpret 0 as integer but only as boolean.

Anyone know how to coerce it to be interpreted as integer? I tried .toInteger() to no avail and the called function setDimmers() requires it as integer: setDimmers(int val)

app:662022-10-27 03:30:46.465 PM warn setDimmers to 1
app:662022-10-27 03:30:41.435 PM warn dimVal = 1
app:662022-10-27 03:30:31.256 PM error org.codehaus.groovy.runtime.metaclass.MissingMethodExceptionNoStack: No signature of method: java.lang.String.call() is applicable for argument types: () values: [] Possible solutions: wait(), any(), wait(long), any(groovy.lang.Closure), take(int), each(groovy.lang.Closure) (setDimmers)
app:662022-10-27 03:30:26.209 PM warn dimVal = 0

While it's not explicitly documented as such, I am pretty sure the data key is supposed to take only a Map as a value (not an Integer or any other type, and despite the fact that it does appear to work with some of these). I was not able to replicate this finding using 0 as keys or values inside such a Map, FWIW, though I suspect that is not what you were trying.

Hi @bertabcd1234 and thanks for the answer.

It is strange because my code does send the paramater as a map value [data: value]:

runIn(seconds, method, [data:value])

And only when value = 0, then I get the error... and only then. Looks more like a bug, don't you think? Especially knowing that this particular runIn() function has been running for years now.

EDIT: After writing the below, I think I realize that there is a miscommunication. If you mean that value above is literally 0, then the data key does not have a Map as its value, and this is the problem I mentioned above. Note that the working example is a nested map, as data itself is already inside the (optional) options Map.


I am not able to replicate that finding, either, and it's not clear from your Logs snippet where the problem actually is.

With this code:

void appButtonHandler(String btn) {
    runIn(5, testHandler, [data: [testKey:0]])
}

void testHandler(data) {
    log.trace "In testHandler()"
    log.trace "data = $data"
}

I get this output, which is what I expect:

Thanks again and sorry if I don't get what you're trying to say! :slight_smile:

Why should dimVal be parsed as a Map? I get that once you pass it as a nested Map you get to retrieve the value from the "testKey" and I guess I could try. But is this a required syntax : [data: [testKey:0]]? If so, it's strange.

There's no reason that I can see why it should be a nested map. The "data" entry already being a key attached to a value, exactly like your nested map "[testKey:0]".

To clarify, my code is as follows:

I have a handler that calls a method named "setDimmers" but with a required delay of 5s:


log.warn dimVal // I log the value I'm passing
runIn(5, setDimmers, [data:dimVal]) // No reason for dimVal to be a nested Map... 


def seDimmers(int val) {
           log.warn "setDimmers to $dimVal" 

}

Now, if and only if dimVal is 0, then I get the Exception. For any other integer (even negatives values), the value is passed.

Again, I'm not sure, but I'm thinking the data key in the options Map is is supposed to take a Map as a value. It's not explicitly documented this way, so I don't really know, but it's in all examples I've seen, including the ones in the docs themselves:

It's possible this assumption is wrong and it's supposed to be able to take any Object, but the odd behavior you noted above suggests that it maybe isn't. I guess @gopher.ny would be the one to ask (and then I can make sure the docs clarify this if needed :slight_smile: ).

2 Likes

that's the problem with some interpreted languages... data types requirements can be blurry at times! Thanks again, especially for the documentation!

Thanks again @bertabcd1234!

Now I'm curious, though :slight_smile:

Maybe @bravenel can help understand how it is possible that for several years I was able to use this syntax without apparent issues: [data: value] directly instead of [data:["key":"value"]]. At the time I based my use of this method on a post that showed it with this wrong syntax (only to find out yesterday that this was corrected at the very bottom of the thread... and the doc was not yet written back then, I think).

More interestingly, why this error started showing only after one of the 2.3.3.13x updates and not before?

Moreover, how can a non-zero value be passed without issue while a zero value won't? I'm asking only out of curiosity so I'd understand if you don't have time to answer, of course.

As far as I know (and have always done) there must be a map for data. The handler called has to pull the value out of a map. To the best of my knowledge this has always been the case.

I didn't know, nor would have expected, that [data: value] approach would work. That it works for some values and not others I have no idea about or any useful knowledge. That it would stop working could be from any number of things, including work done on runIn handling that was recently undertaken.

Is there some reason you can't use the proper form: runIn(secs, handler, [data: myMap])?

1 Like

I'm using it now, of course. It's just stunning that I was able to run my app for so many years without it until it started generating this error - especially with this 0 value being the sole exception... So I was just curious as to what could cause this.

Thanks for your answer! :slight_smile:

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.