Friendly Error points to executing line in the p5.js file, not the line causing the issue

[Namrad]

Most appropriate sub-area of p5.js?

• [ ] Accessibility
• [ ] Color
• [ ] Core/Environment/Rendering
• [ ] Data
• [ ] DOM
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [ ] p5.strands
• [ ] WebGL
• [ ] DevOps, Build process, Unit testing
• [ ] Internationalization (i18n)
• [x] Friendly Errors
• [ ] Other (specify if possible)

p5.js version

2.0.5.

Web browser and version

Vivaldi 7.6.3797.63 (Stable channel) (arm64)

Operating system

Apple M4 Max, Sequoia 15.6

Steps to reproduce this

No real 'steps' involved. Just ran into this while transferring to p5.js 2.0.5:

While using VS Code: When reading the console the Friendly Error message points to the line in the p5.js main-file that executes the Friendly Error message itself, rather than what caused the Friendly Error message in my own .js file.

Because of this I had to manually go over all instances of createVector() and float(), to see where the error came from.

The friendly error messages are really helpful as opposed to the 'unfriendly ones', especially for autodidact coders like me. Maybe therefor this is not necessarily a bug, but more a feature request. I hope this is helpful either way. Sorry if this is an incorrect bug report.

Instances:

1. When passing NaN into a createVector() method.
2. When using float() method incorrectly.

Snippet:

function setup() {
  let vectorA = createVector(10, NaN);
  let vectorB = createVector(vectorA.x + vectorA.y, vectorA.y);
}

function setup() {
  let divisor = 2;
  let time = float(frameCount / divisor);
}

[sahilsharda]

Hey, I’d like to work on this issue and help get it fixed. I’ve gone through the problem and I think I can contribute a solid solution. Please assign this to me if it’s available.

[Mario5T]

The Fix

Modified validate_params.js (lines 608–672) to:

• Detect the p5.js library file name by throwing a test error and parsing its stack trace
• Filter out all frames from the p5.js library to find the first frame from user code
• Use the user's code frame for error location reporting
• Maintain backward compatibility by falling back to parsed[3] if no user frame is found

This approach mirrors the logic already used in the processStack() function in fes_core.js for handling global errors.

---

#Testing

The fix can be tested with the examples from the bug report:

function setup() {
  let vectorA = createVector(10, NaN);  // Error will now point to this line
  let vectorB = createVector(vectorA.x + vectorA.y, vectorA.y);
}
function setup() {
  let divisor = 2;
  let time = float(frameCount / divisor);  // Error will now point to this line
}

[perminder-17]

Hi @Namrad , thanks for opening this. This is for sure not a bug and I think this is the intended behavior of the FES now.

Why: Because FES doesn’t throw, it just logs a helpful message. When you don’t throw, the top stack frame naturally points to the place inside p5.js where the message was emitted, not to your sketch line. This keeps the “don’t stop execution” stuffs, execution shouldn't be stopped in these scenarios.

Also, @Mario5T I saw your PR and the issue was still not approved to be worked on and also @sahilsharda first showed interest for this one, so first we should wait for the approval of the issue to be worked on.

Since the Friendly Error messages already provide plenty of context, we don’t need any extra complexity to pinpoint the exact line in sketch.js where FES was triggered. What you think?

CC: @davepagurek @ksen0