#D doesn't log undefined
When you `C#D` things, they get `CJSON``C.stringified` (to prevent subsequent changes affecting stored output, this is good). Unfortunately, `CJSON``C.stringify(undefined)` yields `Cundefined`, which apparently is getting skipped somewhere
A common issue this causes is a loop over an array that might contain `Cundefined` or go out of bounds. you get "cannot read property X of undefined", stick in a `C#D` in the loop, the `Cundefined` is skipped, so it looks like it breaks on the object before, which prints cleanly. Example code and output:
`Vfunction`(c, a) {
`Vvar` `lpts`=[{`Nx`:`V1`,`Ny`:`V2`},{`Nx`:`V3`,`Ny`:`V5`}];
`Vfor`(`Vvar` `li`=`A0`;`li`<=`lpts`.`llength`;++`li`) {
#D(`lpts`[`li`])
if(`lpts`[`li`].`lx` > 20)`ldoStuff`()
}
`Vreturn` "done"
}
{`Nx`:`V1`,`Ny`:`V2`}
{`Nx`:`V3`,`Ny`:`V5`}
`D:::TRUST COMMUNICATION:::` TypeError: Cannot read property 'x' of undefined
If `C#D` checked for `Cundefined` and logged something like `C<undefined>` in that case, that would make the output for the above code look like this:
{`Nx`:`V1`,`Ny`:`V2`}
{`Nx`:`V3`,`Ny`:`V5`}
`C<undefined>`
`D:::TRUST COMMUNICATION:::` TypeError: Cannot read property 'x' of undefined
Which is MUCH easier to understand and fix
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -