[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.

[vaishnavirrapolu-06]

@limzykenneth That’s a great point about the risk of silent failures, especially when FES is disabled or in minified builds. Perhaps instead of a completely silent return, we could ensure that a standard console.error or warning is triggered even when FES is off? Or, we could follow the pattern of other p5.js functions—do you think it would be better to cast the input to a String (making it "null" or "undefined") so something still renders, or should we keep the native error but make it more descriptive than the current split crash?

[limzykenneth]

Additional warning message is largely redundant since the expectation is FES will be around when the sketch is being developed and when finish, FES will be off, ie. at this point there shouldn't be an error already.

Casting null or undefined to string is likely never desired behavior, there are functions that just ignore that function call when invalid parameters are given but I'm not sure it would be the intuitive option here.

[vaishnavirrapolu-06]

Thank you for the feedback, @limzykenneth! I see your point about FES being off during production. If casting to a string isn't the preferred path, would you recommend focusing on making the split crash more descriptive instead? I'm eager to help improve the developer experience for p5.js 2.0.

[saurabh24thakur]

I've been following the discussion and it makes total sense why we should avoid silent failures to stay consistent with p5's pedagogical goals.

As a middle ground, would it be worth adding a manual check at the entry point of text() and textWidth() to throw a more descriptive native error when null or undefined is passed?

Something like: throw new TypeError('p5.js says: text() expected a string but received ' + str).

This would prevent the internal renderer crash while still providing a 'blocking' message that helps the user find the bug, even if FES is turned off...

[limzykenneth]

@saurabh24thakur Throwing an error halts execution and as such could have unintended effect so I wouldn't recommend it. It can exit early and does nothing like other functions but throwing have downstream effect which is undesired. ie. throwing an error is more or less what the issue is talking about.

Edit: Just to clarify (for myself as well), there are two scenarios, one with FES enabled and one with FES disable.

• FES enabled - parameter check will check the validity of the arguments passed to text() etc, so additional messages is not needed.
• FES disabled - no messages are printed by FES. The function should not print additional messages itself because otherwise it will become additional messages in the previous case.

In either case, execution is not blocked by FES and will continue. If the function throws an error at any point, it blocks execution and the whole sketch stops. If it doesn't throw an error, it does nothing and the sketch continues. The behavior of other functions in p5.js when receiving an invalid argument is to do nothing rather than throw an error, so there is a case for that; conversely, not throwing an error is silently failing so could be confusing in the case where FES is off but I'm not 100% sure that is a common occurrence. The precedent with other functions failing silently and rely on FES when available for me may be enough reasoning to maintain consistency here.

[saurabh24thakur]

Thank you for the clarification, @limzykenneth! That makes a lot of sense—maintaining consistency with p5's 'fail silent' behavior is definitely the priority here.

Based on that, would the preferred fix be to add a simple guard clause at the top of text() and textWidth() that returns early if the input is null or undefined?

This would:

1.Prevent the internal renderer crash..

2.Maintain consistency with other p5.js functions that do nothing on invalid input..

3.Allow FES to provide the warning during development without halting the sketch..