Vvvv throws unrelated Stride exceptions when trying to read settings from a missing or corrupted JSON file

Hey there,

This is on 6.6-0017. When using the new Configuration feature with a JSON or INI file, vvvv will throw seemingly unrelated exceptions on startup if that file is either missing (and marked as mandatory) or badly formatted.

Here’s a screenshot of the exception I’m getting when trying to use a missing file :

The exception is risen on a Stride node which seems like it has nothing to do with loading a JSON config.

I have a attached a repro project which contains this patch and a JSON file which has the wrong name on purpose. To reproduce the bug :

  • Open the attached VL document with 6.6-0017. You should see vvvv instantly pausing and throw this error (might have to press F5 once to see it though)
  • Rename the JSON file to appsettings.json and press F9 : the error should be gone and the patch should start
  • Same thing will happen if you have a malformed JSON (missing coma or something like that)

I also ran into cases where :

  • Trying to read from a non-existing setting would throw similar exception
  • Having it try to read a corrupted/missing file seems to “crash” something, and ConfigItem nodes would not return anything unless restarting vvvv, even when fixing the file as mentioned earlier before

Sadly I could not reliably reproduce those last two things.

Finally, the Expected behavior would be to somehow hint the user that the error is related to the JSON config. Having Stride errors can be quite confusing and one would have to first figure out that the error is related to something totally unrelated (the Config thing). I guess the question is : where do you show that error?

Let me know if needs more details!

Cheers

repro_json_startup.zip (66.5 KB)

While running in the patch editor we’ll now catch and log such exceptions during patch startup. If pause on error is enabled the system should navigate to the crashing node on its own (if it can infer the location from the stack trace). If disabled (default) one will only be able to see the exception in the Debug view (Ctrl + F2). In case the app gets exported such an exception will still lead to crash because we have no proper way to report the exception and simply dropping them might cause even more headaches.

Thanks for the detailed report!

2 Likes