Increasing access
The Friendly Error System (FES) exists to provide beginner-friendly, translatable error messages. When parts of the codebase bypass FES with raw console.log(), those messages cannot be translated via i18n and are not suppressed by p5.disableFriendlyErrors = true. Additionally, when validation errors don't halt execution, invalid data gets silently stored, causing confusing behavior for beginners.
Most appropriate sub-area of p5.js?
Feature enhancement details
Five methods in src/data/local_storage.js use raw console.log() for validation errors instead of the Friendly Error System. Worse, some of these validations don't prevent the invalid operation from proceeding.
Affected locations in src/data/local_storage.js:
| Function |
Line |
Message |
Blocks execution? |
storeItem() |
L125 |
Non-string key warning |
❌ No — stores anyway |
storeItem() |
L130 |
Key ending with p5TypeID warning |
❌ No — stores anyway |
storeItem() |
L136 |
Undefined value warning |
❌ No — stores anyway |
getItem() |
L283 |
Unable to determine stored type |
❌ No — continues |
removeItem() |
L447 |
Non-string key warning |
❌ No — removes anyway |
Example of current code:
// storeItem() at line 123
p5.prototype.storeItem = function(key, value) {
if (typeof key !== 'string') {
console.log(
`The argument that you passed to storeItem() - ${key} is not a string.`
);
}
if (key.endsWith('p5TypeID')) {
console.log(
`The argument that you passed to storeItem() - ${key} must not end with 'p5TypeID'.`
);
}
if (typeof value === 'undefined') {
console.log('You cannot store undefined variables using storeItem().');
}
// ⚠️ Execution continues even after errors above — invalid data gets stored!
let type = typeof value;
// ...stores the value anyway...
};
Two problems here:
-
FES bypass: All 5 messages use raw console.log() instead of p5._friendlyError(), so they aren't suppressed by p5.disableFriendlyErrors = true and can't be translated via i18n.
-
Missing early returns: storeItem() logs the error but still proceeds to store the invalid key/value. For example, passing an undefined value logs a warning but still calls localStorage.setItem(key, undefined). Similarly, removeItem() warns about non-string keys but still tries to remove.
Expected behavior:
These validation messages should use p5._friendlyError() and the functions should return early after detecting invalid input, so that invalid data is not silently stored or removed.
Additional context:
This is consistent with ongoing efforts to migrate raw console.log/console.warn calls to FES across the codebase. The p5.TypedDict module in the same Data sub-area has similar patterns.
I'd be happy to work on this if it gets approved!
Increasing access
The Friendly Error System (FES) exists to provide beginner-friendly, translatable error messages. When parts of the codebase bypass FES with raw console.log(), those messages cannot be translated via i18n and are not suppressed by p5.disableFriendlyErrors = true. Additionally, when validation errors don't halt execution, invalid data gets silently stored, causing confusing behavior for beginners.
Most appropriate sub-area of p5.js?
Feature enhancement details
Five methods in
src/data/local_storage.jsuse rawconsole.log()for validation errors instead of the Friendly Error System. Worse, some of these validations don't prevent the invalid operation from proceeding.Affected locations in
src/data/local_storage.js:storeItem()storeItem()p5TypeIDwarningstoreItem()getItem()removeItem()Example of current code:
Two problems here:
FES bypass: All 5 messages use raw
console.log()instead ofp5._friendlyError(), so they aren't suppressed byp5.disableFriendlyErrors = trueand can't be translated via i18n.Missing early returns:
storeItem()logs the error but still proceeds to store the invalid key/value. For example, passing an undefined value logs a warning but still callslocalStorage.setItem(key, undefined). Similarly,removeItem()warns about non-string keys but still tries to remove.Expected behavior:
These validation messages should use
p5._friendlyError()and the functions shouldreturnearly after detecting invalid input, so that invalid data is not silently stored or removed.Additional context:
This is consistent with ongoing efforts to migrate raw
console.log/console.warncalls to FES across the codebase. Thep5.TypedDictmodule in the same Data sub-area has similar patterns.I'd be happy to work on this if it gets approved!