p5.js
p5.js copied to clipboard
Some p5.js functions do not make a call to _validateParameters (FES)
Topic
I was not sure whether this was a bug or intentional behaviour, so I filed it under discussion...
I have noticed that a large number of functions do not make a call to _validateParameters(), while others do. This leads to different types of error messages being produced when incorrect parameters are passed to each of them. For example:
fill() and stroke() both do not make a call to _validateParameters(). The error message is as follows:


However, the functions which do have a call to _validateParameters() have a different ( friendlier) error message, as illustrated by the example of constrain():

Is there a specific reason for this, or is this a bug?
The validateParameters function is not able to handle all kinds of function signature that we use, so there will be some functions that just doesn't work with validateParameters. If you find some that could work but isn't using validateParameters you can list them here.
I believe that those examples should use the FES's _friendlyError function. This will allow them to internationalise to the programmer's desired language instead of being hard-coded in English. Additionally, they will be easier to unit test and will be able to be displayed using colour in the console.
Some more examples can be found by searching for "new Error" and "throw new", "console.warn" and "console.log" although "console.log" has a lot of false positives.
This could probably be tagged with Good First Issue if it is deemed important to use the Friendly Error System.
along the same lines, do we have any standard mechanism for warnings ?
If I am not wrong, we have to add a new line which uses _friendlyError to validate all the parametes to all the functions whose parameters are not validated, but needed to be.
is this issue still open ? if yes i would like to work upon it please assign this to me.
Ideally validating parameters go through validateParameters only, otherwise it can make things difficult to maintain further down the line, so I wouldn't suggest adding _friendlyError to all functions that's not covered by validateParameters already.
If there are places where console.error or console.warn are still being used, we can switch these to use _friendlyError as that's what it's for anyway.