[p5.js 2.0 Bug Report]: text() and textWidth() throw runtime errors after friendly error is shown

[shuklaaryan367-byte]

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
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

2.2.0

Web browser and version

Google Chrome Version 144.0.7559.61

Operating system

Windows 11

Steps to reproduce this

Description:
When invalid input is passed to text() or textWidth(), a friendly error message is correctly shown, but execution continues and results in a runtime exception inside the text renderer.
This appears inconsistent with other APIs where execution stops after a friendly error.

Steps:

1. Open the p5.js Editor
2. Run one of the following sketches
3. Observe console output

Snippet:

function setup() {
  createCanvas(200, 200);
  text(null, 50, 50);
}

function setup() {
  createCanvas(200, 200);
  console.log(textWidth(null));
}

Expected Behaviour:
After a friendly error is reported, execution should stop or fail gracefully without throwing an internal runtime exception.

Actual Behaviour:
A friendly error is shown, but execution continues and crashes inside the text rendering internals.

Additional Notes:

• This behaviour is reproducible with null and undefined
• Similar friendly-error-then-crash patterns were not observed consistently across other APIs
• The crash originates from Renderer._processLines

I'm happy to take this on if this gets approved

[vaishnavirrapolu-06]

Hi @davepagurek! I've been following the report by @shuklaaryan367-byte and I've been exploring the p5.js 2.0 source code. I see exactly how the text(null) call is bypassing the FES check and hitting a runtime error in the Renderer. Since I've already contributed documentation to the project, I'm ready to take on this code-level fix to ensure a graceful early return. May I be assigned to this issue?

[davepagurek]

I'm actually not 100% sure that it's the job of FES to prevent internal errors as long as a warning is logged first. That could be something we want, I'm just unclear on what the general expectations are. @limzykenneth do you have thoughts?

[limzykenneth]

FES never halts execution as that will change the underlying behavior of the implementation. It is only meant to print helpful message so that in the case when an actual error occurs, a more helpful message is also available, ie. it also does not suppress native error messages. Having both the native error messages and FES side by side provides a learning opportunity for environment outside of FES and thus is an important pedagogical design decision as well.

[shuklaaryan367-byte]

@davepagurek @limzykenneth Thanks for the clarification, if it is an intended behaviour, should I close this now?

[vaishnavirrapolu-06]

Thank you for that clarification @limzykenneth and @davepagurek! I completely agree—FES should stay as a helpful guide without halting execution. Since we still want to avoid the native split crash in the Renderer, I’d love to implement a guard in the typography functions to handle null/undefined inputs gracefully. This way, the user gets the FES warning and the sketch keeps running without a runtime error. May I take this on?

[limzykenneth]

@vaishnavirrapolu-06 It depends on whether silent failure in the case of null argument something that is desired. The user does not always have FES warning (it can be turn off and it is not included in minified version) so that is not something to rely on. Silent failure in this case may be more confusing that a blocking error message, eg. imagine passing a variable that is mispelled and so have its value be undefined, this passed into a silently failing function means that what the user expect to be drawn is never drawn but there is no indication anywhere why that is the case.