friendly error system fixes, updates, and improvements

[lmccart]

The friendly error system was first implemented at the p5.js contributors conference. It is an effort to provide more human readable and friendly error messages in console. It also does some minimal argument type checking since JS does not do this. The nice thing about it is that it is only added to the p5.js build of the library, and eliminated from p5.min.js to improve performance speed. However, there are a number of issues and extensions that are required before it's fully up and running.

I think the FEs would benefit from one person taking this on as a sort of concentrated project. It could be a good Processing Fellowship or Google Summer of Code project. For organization purposes, I am aggregating all the Friendly Error related issues here for now. I will close but link to all other issues. If someone were to tackle this project, the first step would be to read through all the issues and devise a roadmap and plan of attack.

• validateParameters can't support multiple-type parameter - for example, methods dealing with color often can take either a color object or a number as an argument. however, the validateParameters() function doesn't support this.
• Friendly Error Messaging for unsupported browsers - it would be nice to have messages that alert the user if they are trying to use functions of p5 that are not supported by their browser.
• Friendly Error Messaging should show sketch line number
• Generate Friendly Error Messaging from existing documentation - it would be nice to auto-generate the parameters accepted by each function from the reference, rather than having to manually add them to each function in the code.

These two pages describe some more thinking around it, currrent status, and future plans/ideas:

• https://github.com/processing/p5.js/wiki/Friendly-Debugger
• https://p5jscon.hackpad.com/Error-Reporting-6UAUU37d6j9

[shiffman]

I'll just add a short note here that the recent Processing 3 implemented custom error messages for the first time (developed originally as part of "PDE X" by @Manindra29) -- the goals were to give more specific info about syntax errors as well as provide friendlier language and reduce scary Java-specific (and often misleading) messages. If / when this project gets more development time, I'd be happy to help offer resources and information about some of the questions and solutions that came up during the Processing development.

For example, one thing that was helpful was just maintaining a spreadsheet of all the common errors, what causes them, and ideas for new language.

[darkcoderrises]

HI, I would like to work on this. Can someone mentor me on this?

[lmccart]

hi @darkcoderrises, thanks for your interest! we don't really have a general mentor system for larger issues like this, but you could propose this as a fellowship project and a mentor would be assigned in this case.

however, if you're looking to get involved right now and learn a bit about the p5.js development and codebase, and get some general feedback and pointers as you work, I'd suggest starting with some of the smaller issues. anything labeled level:beginner would be good ones to get started with.

take a read through this development doc as a starting point. this gives an overview of the workflow, code organization, and building and testing process. please let me know if you have any questions or if anything is unclear!

[lmccart]

Following up here on a point from #1512 (comment):

I think it's no problem to just have the editor link to the minified version. But I agree it could be confusing that the unminified version is slower than the minified version, and it might make more sense for friendly errors to be a separate addon. I guess we have to weigh that against the benefit of having beginners feel taken care of with the core library without addons.

[mikewesthad]

@lmccart I was just about to follow up in #1512. What about a check for p5.disableFriendlyErrors when p5 is creating the global sketch instance? Then a sketch that wants the performance that comes from disabling the friendly errors would look like:

p5.disableFriendlyErrors = true;

function setup() { }
function draw() { }

Since the global sketch isn't created until after the page is loaded, any user defined sketches should run before the friendly error binding happens. Beginners would be taken care of by default, and it would be easy for advanced users to get the performance boost when needed.

[lmccart]

that seems very reasonable, and it adds a good additional option besides having to swap out to minified p5.js... since sometimes it is nice to be able to work with readable library source code.

[lmccart]

I'm going to close this issue as this has been mostly addressed. we can break down further bugs and features in more specific issues. thanks @almchung for getting this rolling again last summer!