Allow Stringify to convert JS objects for debug output.
Details
Diff Detail
- Repository
- rP 0 A.D. Public Repository
- Branch
- /ps/trunk
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 1386 Build 6289: Vulcan Build (Windows) Jenkins Build 6288: Vulcan Build Jenkins Build 2184: Vulcan Build Jenkins Build 2183: arc lint + arc unit
Event Timeline
Build has FAILED
Link to build: http://jw:8080/job/phabricator/955/
See console output for more information: http://jw:8080/job/phabricator/955/console
That's also hitting GUI and JS Simulation, so we should be really sure that this is wanted in all case.
What about an error stack? In #3965 we had this conversion error without any indication where it occured and had to put prints all over the engine code to locate it.
The #define miight be nicer to read with newlines.
I'm dubious about always stringifying this - try stringifying one or another massive object and it will segfault instead of printing the error (At least I always got them when stringifying too big stuff from JS)!
To me it's a won't fix, the feature doesn't seem to add something useful while adding disadvantages.
- JSON.Stringify won't work for functions
- This string can be indefinitely long, it can be very noisy.
- The error should (and does) show the value type, but the actual value shouldn't matter.
- In most cases we can reproduce the error (simulation, rmgen), so we can display the value if really needed. In the GUI we have to start investigating, most often its only undefined property. Then we don't need the patch either.
Patch as is not acceptable as mentioned above, because JSON.stringify does break for many values (undefined, Set, functions), because too long values are too noisy. What the user really needs is a stacktrace where the error occurs rather than trying to guess from the value what might go on. Notice that if the same conversion function is called in JS and warns, we get a JS stacktrace, but if this function is called from C++ we don't.