Bogus referenceError?

pyeager

And here is an example of a scripting data source that suddenly quit working:

var sources = DataSourceQuery.query('like(name,polecat*VIRT)&limit(10)');
for(var i = 0; i<sources.length; i++ ) {
    
    var source = sources[ i ];
    WaterControl( source.xid );
    RelayLink( source.xid );

}

Validation of this script generates the very same error message:

ReferenceError: "wetBulb" is not defined at line: 134

WaterControl and RelayLink are global scripts.

WaterControl declares wetBulb at line 26, and references it at lines 38, 41, 45, and 49.

RelayLink makes no reference whatsoever to wetBulb.

Attempts to validate WaterControl and RelayLink result in the exact same error message shown above in this post.

terrypacker

@pyeager

You have a syntax error in the 1st script you posted. It has the correct number of parenthesis but the ordering is such that some of the code is outside of a function block.

Since every global script is executed anytime you execute or validate any Mango JavaScript this results in the code being executing and various variables not being defined in the block of code that it outside the function blocks of your global script.

You have an errant } on line 17:

        if( point.name == "Auto Throttle" ) {
            var at = point.runtime.value;
            print( "Auto Throttle " + at );
            }
        }

pyeager

Terry:

Thanks for pointing out my syntax error.

Is it unfair to expect that the script error message point to the actual error, and perhaps even the file in which the error exists?

Also, where would I find scripts so that I can edit them with an editor I am more accustomed to?

phildunlap

Did the validation on the global script itself not do this? It wouldn't identify where the errant } was, but it would surely point out that it doesn't run properly and where it failed to do so.

pyeager

The error message says nothing about what file the error occurred in, and when it indicates the location of an error, the indicated line bears no relationship to the reported error.

One might assume the error exists in the script being validated, but we know that is not the case.

phildunlap

You are again talking about the validation of the point, yes? When the global script was modified, did not that validation show it?

pyeager

The error message was exactly the same, no matter which script was being validated.

The error message pointed to a line in some script, but never to a line referencing the variable noted in the error message.

phildunlap

No, the script editor on the global script would have shown you the line it encountered trouble at.

The point is taken that a message on other scripts could suggest the global scripts are where the error is. But, it is good to test scripts when you modify them. Currently the validation on the backend will prevent saving syntax errors, but the error here is at runtime in referencing an undefined. We could modify the validation to execute the script, as the validate button on the global scripts page does.

pyeager

@phildunlap said in Bogus referenceError?:

No, the script editor on the global script would have shown you the line it encountered trouble at.

Rather than continuing to insult my intelligence, would you please re-read my initial post?

My initial post includes a complete global script, as was pointed out in a subsequent message.

The error message most certainly did not point to the location of the error.

phildunlap

Okay, I think I know what happened. I was talking about these things,

But I was able to get it misaligned and reporting less than helpful line numbers by using more global scripts, Thanks for bringing that to our attention. I also saw that if I had saved the script with an error in it, then subsequent modifications of the script would still produce the same error until saved, which was caused by trying to add the saved version of the global script into the script engine, which doesn't seem quite right.

Curious that I didn't see the same validation error as you.

Edit: It appears the line numbers can only get off this way by saving a global script that produces this sort of error. If the global script does run without error, the line numbers for issues in the scripts in meta points and scripting sources should be correct when those then have syntax or reference errors.

pyeager

Thank you for taking a second look.

Clearly, your test did not duplicate my situation.

Your test referenced a value that in fact did not exist, and produced an error message that pointed to the reference accurately.

In my situation, as stated early on (four days ago, in fact), there was no reference to the variable called out in the error message anywhere near the line called out in the error message.

Furthermore, as it turns out, the error message had absolutely nothing to do with the problem. It was improper placement of curly braces. There was in fact no reference to an undefined variable. All of this is documented here on this thread.

phildunlap

Thank you for taking a second look.

Certainly.

Clearly, your test did not duplicate my situation.

I could have posted a screenshot of it putting the error marker on line 42 where it didn't belong, as I alluded to in saying I was able to achieve it by using multiple global scripts. Did you only have one global script? The only way I saw to achieve it there is also documented in my previous post, saving the one with the error and then trying to validate some revision of it.

Your test referenced a value that in fact did not exist, and produced an error message that pointed to the reference accurately.

In my situation, as stated early on (four days ago, in fact), there was no reference to the variable called out in the error message anywhere near the line called out in the error message.

The global scripts are executed by the script engine before the meta point / scripting data source / event handler / etc and that is where the line number and message were coming from. Furthermore for efficiency all global scripts are bundled together before being handed to the script engine, so that's where the line number can be off even relative to the global scripts' line numbers.

Furthermore, as it turns out, the error message had absolutely nothing to do with the problem. It was improper placement of curly braces. All of this is documented here on this thread.

Yeah, the function block was closed to early and there were statements that referenced things which weren't defined. The script engine has no way of knowing where a curly brace in defining a function body went wrong...

pyeager

Did you only have one global script? The only way I saw to achieve it there is also documented in my previous post, saving the one with the error and then trying to validate some revision of it.

Yes, I have several global scripts.

Perhaps it might help to warn users that having multiple global scripts might make finding errors more difficult. Or better yet, modify things so that the error message details what script and/or function the error occurs in.

phildunlap

Perhaps it might help to warn users that having multiple global scripts might make finding errors more difficult.

I have created three git issues for this thread, two private one public. Issues being,

Execute global scripts in save validation to ensure they execute (as opposed to compiling, which is what is done now, and would catch syntax errors)
Do not add global scripts to one another during validation of global scripts
Report exceptions from global functions better: https://github.com/infiniteautomation/ma-core-public/issues/1462

Edit: they're only private because global scripts is in one of our private repositories

pyeager

Thank you!