· May 18, 2021

Unexpected Token Error in VS Code

 I'm trying to set up VS Code for ObjectScript using the instructions found here. I've got both Cache 2018.1.2.309.0 and IRIS 2020. When I try to connect to either one of them the connection fails, and I get a notification in the bottom right corner that says "Unexpected token < in JSON at position 0". I've checked the JSON settings file that VS Code uses, and they're fine and formatted properly. All of the settings I've entered are correct. I suspect that there's a response coming back from the server that VS Code is expecting to be JSON, but isn't. It pops up any time I click on anything under "OBJECTSCRIPT:EXPLORER" or any time I click on a different tab at the top.

I have no idea where to go to even begin troubleshooting this. Has anyone else had this issue come up, or can someone point me where to go to figure out what's going on?

The contents of my settings.json are:

    "intersystems.servers": {
        "cache2018": {
            "webServer": {
            "description""Cache 2018.1.2.309.0",
    "objectscript.conn": {

Product version: IRIS 2020.1
Discussion (20)1
Log in or sign up to continue

After a lengthy discussion, you still seem not to be aware of what information you send and what is coming back.
It may help just to watch your communication using TcpTrace or WireShark to find out what ERROR to chase at all.

As I distrust your initial JSON construct I checked my personal opinion with
a public JSON validator.
Info: Remove trailing commas.

But this was pointed out correctly already before me by @Julius Kavay 

For the sake of completness, there is one more validator:  (which shows the above settings.json file as incorrect).

One more problem, it seems IRIS (and Cache) speaks with a forked tongue (but has nothing to do with the above problem) :

set string = "{""Value"":123, }"    // note the extra comma!
set stream=##class(%Stream.TmpCharacter).%New()
do stream.WriteLine(string)
set obj1={"Value":123, }  --> gives a SYNTAX
set obj2={}.%FromJSON(string) --> accepts the incorrect (json)string!

OK, take a more simple case:

set obj=[1,2,,3]  // again, this is a SYNTAX
set obj=[].%FromJSON("[1,2,,3]") // this is OK

but in both cases, the problem was the bouncing comma-key on my keyboard.

The first was told by compiler the second was "forgiven" by JSON-Reader! BUT the real question is, WHAT IS the third item in the above array? The latter shows obj has a size of 4, so the, and the desired thrid element could be null, 3 or maybe something else!

I wrote my very first program somewhere in 1971 or 1972, I can't remember anymore. But one thing I have learned is, one should accept checked data only.

Imagine, you accept those incorrect (aka forgiven) data and beside processing, store the data in your database, then later, for whatever reason, you send the (original string) data to an external party.... bang! They can't read it, because it's not JSON conform.

[1,2,,3] is arguably more ambiguous than a trailing comma, and there are some precedents for (if and) how to treat trailing commas.

On the other hand, I just tested both cases in Firefox using JSON.parse() and they both fail. Browsers tend to be pretty tolerant of bad stuff, so the fact that Firefox won't accept trailing commas makes a good case for IRIS not allowing trailing commas either.

Strangely, Firefox apparently allows trailing commas in JavaScript, but not in JSON.

[1,2,,3] is equally arguably as [1,2,3,,] or [1,2,3,,,,,] and IRIS/Cache accepts all of them.

Nothing against a system which is input tolerant (forgiving, with your words) but then this tolerance should be obvious and in some way logical. An example, I tolerate trailing comma(s), becuse they could be leftovers of editing. So I would say, all the arrays


have a size of 3 - there are three elements, no more. But IRIS/Cache says the sizes are 3, 4 and 6. So let check  the last one

set obj=[].%FromJSON("[1,2,3,,,]")
write obj.%Size() --> 6
for i=0:1:9 write i,?3,obj.%Get(i),?7,obj.%GetTypeOf(i),!

The output of the FOR-Loop is:

0  1   number
1  2   number
2  3   number
3      unassigned
4      unassigned
5      unassigned
6      unassigned
7      unassigned
8      unassigned
9      unassigned

The elements with index 3, 4 and 5 are unassigned and in some kind, I can understand that. But if the higher indices, like 6, 7, 88 or 1000 etc. are also unassigned then I ask you, why is the size 6 and not, say 12 or 573?
For me the logical size should be 3 because there are three intendeed elements, the others are a result of tolerated delimiters! 

Finally, I don't want to start a war, how to interpret JSON strings. It was just my 2cc to a theme, which is out-of-round, according to my opinion.