I’m using xojo.Data.ParseJSON to parse a JSON file into a xojo.Core.Dictionary object. I’ve found that a particularly large JSON file is causing an exception in my production code, yet if I chop exactly that same code out and put it in a test project, it works fine. The code in question is pretty simple:
[code] dim messagesContents as String
dim messagesJSON, appNameJSON as xojo.Core.Dictionary
enLocaleFolder is a FolderItem representing a folder containing the messages.json file, nameKey is a string containing (in this case) “ExtensionName”. I have verified that this key does exist, and is properly retrieved when this code is placed in a test project. In my production code, though, appNameJSON ends up being nil, resulting in a NilObjectException being thrown. (Everything’s in a try block, so the failure is at least handled gracefully.)
Worse, after my code runs into this failure, the app runs very sluggishly. If I remove the folder containing this particular problem messages.json file from the list of folders being examined this way, everything works fine, but as soon as this code sees that file, everything takes at least 5 times as long.
What’s going on here, and how can I solve it? Is there some kind of buffering issue? Am I overflowing some kind of buffer in xojo.Data.ParseJSON with my production code, and that’s not happening in the test code? The problem messages.json file is 84k.
Try doing the ToText conversion into a Text property. I’m curious if the exception is actually there and that somehow the incoming data is actually not UTF8.
Makes no difference. I stuffed messagesContents.ToText into a Text variable, and the only thing that I noticed was that trying to look at, or scroll, the contents of that variable in the debugger caused Xojo to become unresponsive for about 30 seconds. However, the text it contains is identical to the contents of the file being read in. (I compared the two using TextWrangler.)
I can actually look at the messagesJSON object in the debugger and see that it does, in fact, have the key that I’m looking for. But for some reason the Lookup call is failing.
The fact that this affects the performance of the app long after this routine has been called (and it only gets called once) seems to me to be the hallmark of a bug in Xojo’s frameworks somewhere. I just don’t know how to work around it.
I’m not sure how it could be an encoding issue, since the same file and the same code works fine when plucked out and put in a test project. If it were an encoding issue, wouldn’t it affect any project using this code with this file?
Could you create a private Feedback case and attach that file? If we can reproduce it and confirm its a bug, maybe we can fix it (or explain what’s going on).
Just out of curiosity… What’s the exception being thrown?
[quote=200322:@Greg O’Lone]Could you create a private Feedback case and attach that file? If we can reproduce it and confirm its a bug, maybe we can fix it (or explain what’s going on).
Just out of curiosity… What’s the exception being thrown?[/quote]
Done… just submitted case 40146. It has the troublesome messages.json file attached. I was not able to attach a project showing the error, because I’d have to submit the full source code for my app… I haven’t found a way to reproduce the error in a sample project.
As for the exception, it’s a NilObjectException, because appNameJSON is nil… but it shouldn’t be, because the key the code is looking for is definitely in the file, and I’ve verified in the debugger that it’s in the messagesJSON data. The code shown above is wrapped in a try block, as I expect that this may fail sometimes… however, in this case it definitely shouldn’t be failing, and it’s odd that it has such a marked effect on the system’s performance afterwards.