Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some p5.js functions do not make a call to _validateParameters (FES) #5649

Closed
Tracked by #6469
reejuBhattacharya opened this issue Mar 29, 2022 · 6 comments
Closed
Tracked by #6469

Comments

@reejuBhattacharya
Copy link
Contributor

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:

image

image

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

image

Is there a specific reason for this, or is this a bug?

@reejuBhattacharya reejuBhattacharya changed the title Some p5.js functions do not make a call to _validateParameters Some p5.js functions do not make a call to _validateParameters (FES) Mar 29, 2022
@limzykenneth
Copy link
Member

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.

@Qianqianye Qianqianye added this to the 1.5.0 milestone Jul 27, 2022
@stampyzfanz
Copy link
Contributor

stampyzfanz commented Sep 30, 2022

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.

@dhowe
Copy link
Contributor

dhowe commented Sep 30, 2022

along the same lines, do we have any standard mechanism for warnings ?

@aditya-shrivastavv
Copy link
Contributor

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.

@limzykenneth
Copy link
Member

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.

@limzykenneth
Copy link
Member

Being addressed in #7178 for 2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants