[devtools-rfc] Differentiate error messages for strings, errors, uncaught exceptions...
Categories
(DevTools :: Console, task, P3)
Tracking
(Not tracked)
People
(Reporter: jdescottes, Unassigned)
References
(Blocks 1 open bug)
Details
The error level in the console can be used in various situations:
console.error("some message")console.error(caughtErrorOrException)- and uncaught exceptions
Today, they are displayed very similarly in the console. The goal here is to discuss if it would make sense to display them slightly differently.
This discussion came about when looking at Bug 1655838, and I'm going to focus on the point of view of the DevTools codebase for now.
One of our internal helpers logs an error when we try to localize a string but can't find the provided key. This is normally pretty bad and should be addressed by the developer during development, but we also didn't want to throw anymore because there are cases where a key can be missing temporarily from a localized build, and throwing might break the consumer. So it felt like a good use case for console.error: it's bad enough that you should fix it if you see it during development, but if it randomly happens at runtime we don't want to break DevTools.
But this error message was misleading. A team member encountered a broken webconsole panel, saw this error in the Browser Toolbox, and logically thought that the console was broken because of this error.
Should we make various errors look different, so that uncaught exceptions look more severe than console.error("someString")? Or should we simply say that errors which don't break the application should only use console.warn and not console.error?
|
||
Comment 1•6 years ago
|
||
But this error message was misleading. A team member encountered a broken webconsole panel, saw this error in the Browser Toolbox, and logically thought that the console was broken because of this error.
This seems like a separate problem though, as warn might have been used for this severity as well (but is sadly overused on the Browser Console level).
Should we make various errors look different
An important constraint is how frameworks depend on console.error to "re-throw" caught and processed JS errors on the framework side. Apart from the UI needs, this use case has it own improvements (like how Console displays the stack). So I generally agree that error-type arguments and strings can be treated differently.
Description
•