Improve FES messages for strands color functions (#8914)#8971
Open
manju2810 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #8914
Changes:
Three FES message improvements for strands color functions, as described in the issue:
lerpColor()missing/wrong arguments — previously reported the internalmixfunction name instead oflerpColor. Added an explicit arg-count check inlerpColor()(src/strands/strands_api.js) solerpColor(c, 0.5)now reports:lerpColor() expects 3 arguments (color1, color2, amount), but 2 were provided.lerpColor()/red()given a non-numeric value — previously threw a generic "non-numeric value" message with no indication of which function or argument caused it.lerpColor()now catches and rewrites this error to name itself and the offending argument index (e.g.lerpColor(c1, "blue", 0.5)→lerpColor() received a non-numeric value for argument 2: blue). A smallstrandsNodeForArghelper does the same forred(),green(),blue(), andalpha()(e.g.red("blue")→red() received a non-numeric value for argument 1: blue). The argument-detection logic recurses into arrays so array-based colors (e.g.[1, 0, 0, 1]) are never misreported as the bad argument.Invalid color string —
color('#fv0a')previously threw a bare"Invalid color string"with no indication of what was invalid.src/color/p5.Color.jsnow includes the actual string:Invalid color string: '#fv0a'.hue(),saturation(),brightness(), andlightness()were left as-is since the issue only called outred/lerpColor/colorexplicitly, but they follow the identical pattern if a maintainer wants them included too.Screenshots of the change:
Verified manually in a browser (inside a
.modify()block) — console output before/after:lerpColor(c, 0.5)→[p5.strands parameter validation error]: lerpColor() expects 3 arguments (color1, color2, amount), but 2 were provided.red("blue")→[p5.strands type error]: red() received a non-numeric value for argument 1: bluelerpColor(c1, "blue", 0.5)→[p5.strands type error]: lerpColor() received a non-numeric value for argument 2: bluecolor('#fv0a')→Invalid color string: '#fv0a'PR Checklist
npm run lintpasses