Check for whether an error is internal needs updating for ES6 classes

[davepagurek]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build Process
• Unit Testing
• Internalization
• Friendly Errors
• Other (specify if possible)

p5.js version

main branch

Web browser and version

Firefox 108.0

Operating System

macOS 12.5.1

Steps to reproduce this

In #6088 we noticed that errors thrown from within a p5 class aren't registered as being internal from FES. This seems to be because the source name in the stacktrace look different when inside an ES6 class and do not include the class name.

e.g. before: (source includes _main.default.Element.prototype)

after: (source does not include the class)

We may need to either update our babel configuration to output the same code structure as before, or update the way we check if an error is internal, which currently happens here:

p5.js/src/core/friendly_errors/fes_core.js

Line 507 in ab3e2ad

if (stacktrace[j].functionName.search('_main.default') !== -1) {

[Qianqianye]

Thanks @davepagurek. I am adding GSoC FES contributor @Ayush23Dash and mentors @almchung @nbriz to this discussion.

[davepagurek]

just thinking out loud here: instead of checking the method name, we know what file errors came from, but the issue is that the file name could be different depending on what CDN or deployment setup is used. We could intentionally throw and catch an error when setting up p5 to see what its file name is, and then compare stacktraces with that to see if something is internal or not?

[davepagurek]

I made a PR for that method above. It seems to be working? Anyone with more FES context than me, I'd love a set of eyes to make sure I haven't missed anything!

[almchung]

Thank you for catching this and suggesting a great solution, @davepagurek! I agree this change would be great, but just in case, I will double-check with @Ayush23Dash and @nbriz how it would work with the decoupling task that we are currently working on.

[Ayush23Dash]

I believe the decoupling task that we are currently undergoing intended to isolte FES from p5, but after some research I believe this is not feasible, hence I think this PR would work fine!!