Roku Developer Program

[abhishek]

In Roku AdFrameworkSample.zip, found on https://sdkdocs.roku.com/display/sdkdoc ... +Framework, the app is giving the following error

BRIGHTSCRIPT: ERROR: Runtime: FOR EACH value is Invalid: roku_ads_lib:/Roku_Ads.brs(2729)

when setting the VAST Url using following line of code as per documentation.

adIface.setAdUrl(VASTUrl)

.

Looks like error handling is not properly done in the Library code.
Can someone please help to sort out this issue?
or
Provide the Source code of Roku_Ads.brs ?

[renojim]

"abhishek" wrote:
BRIGHTSCRIPT: ERROR: Runtime: FOR EACH value is Invalid: roku_ads_lib:/Roku_Ads.brs(2729)

I see that error every time in my working channel, so I don't think that's your problem. However, I see it when I showAds, not when I set the URL. You don't say exactly what problem, if any, that error message is causing.

-JT

[EnTerr]

Bah! Your post spoiled my google-whack. 😛

I reported the error 2 months ago, with no reaction by Roku* so far
viewtopic.php?f=34&t=92104

[RokuKC]

"abhishek" wrote:

...

BRIGHTSCRIPT: ERROR: Runtime: FOR EACH value is Invalid: roku_ads_lib:/Roku_Ads.brs(2729)

...

The error message is due to an optional field check not being guarded in the RAF code.
According to the engineer, this should be a cosmetic issue only on the developer console, and it will be fixed in a future release.

[EnTerr]

Can we also have the diagnostic text changed, RokuKC?

So that it does not say "ERROR" but "WARNING" instead. You may think it's "obvious" but everybody else seems to freak out when they see in console this colon-centipede "BRIGHTSCRIPT: ERROR: Runtime:" (cue multiple previous threads)

I.e. if it's not a fatal exception (execution could/would continue), do not mention "error" in the diagnostic.

[RokuJoel]

"EnTerr" wrote:
I.e. if it's not a fatal exception (execution could/would continue), do not mention "error" in the diagnostic.

Good point, I think.

What do you think @RokuKC?

- Joel

[RokuJoel]

"EnTerr" wrote:
I.e. if it's not a fatal exception (execution could/would continue), do not mention "error" in the diagnostic.

Good point, I think.

What do you think @RokuKC?

- Joel

[RokuKC]

"EnTerr" wrote:
Can we also have the diagnostic text changed, RokuKC?

So that it does not say "ERROR" but "WARNING" instead. You may think it's "obvious" but everybody else seems to freak out when they see in console this colon-centipede "BRIGHTSCRIPT: ERROR: Runtime:" (cue multiple previous threads)

I.e. if it's not a fatal exception (execution could/would continue), do not mention "error" in the diagnostic.

It's working as designed. A usage error doesn't have to be fatal to be an error. 🙂

[EnTerr]

"RokuKC" wrote:
It's working as designed. A usage error doesn't have to be fatal to be an error. 🙂

Do you mean that you consider the scary diagnostic a great design, because it will freak out developers into coding better?

Consider that said design got "hoist with his own petard" in this RAF case - because

1. the channel developers get scared but can do nothing to fix the issue (because of closed source) - while


2. the library maintainer could have but did not bother to fix it (because they knew said "error" is a warning in disguise).

So we got incentive reversal, a cobra effect.^

My modest proposal is to call a spade a spade. All developers that have ever used a compiler are already conditioned there are two distinct kinds of diagnostics spat - errors ("you shall not pass!") and warnings ("fine, i'll do it... begrudgingly. but you'll be sorry, probably") - so play to that strength, use the shared vocabulary

(^) there is a quote by comrade Lenin about what a "revolutionary situation" is - which i will butcher translating to shoehorn it here: "those who can - won't and those who want - can't"