Error handling is unspecified #249
Description
What is the issue with the Console Standard?
There's no specification for how errors during execution of Printer or Formatter should be handled.
This is particularly bad for Formatter, as it can invoke user code, e.g. while converting a user object to a string for %s:
Lines 334 to 335 in 6f299db
ECMA-262's
%String% calls .toString() on its first argument if it's an object (as part of the ToString/ToPrimitive operations).Note that the
Call operation returns a Completion, but the Console Standard appears to treat the return value as if it were a JS value.
Implementation Behavior
Implementations already differ on how they handle errors during formatting.
When evaluating console.log("-->%s<--", { toString() { throw new Error("nope") } }),
Firefox silently discards the log call:
Chrome propagates the error:
As does Node.JS:
> console.log("-->%s<--", { toString() { throw new Error("nope") } })
Uncaught Error: nope
at Object.toString (REPL1:1:46)
at String (<anonymous>)
at formatWithOptionsInternal (node:internal/util/inspect:2310:27)
at formatWithOptions (node:internal/util/inspect:2264:10)
at console.value (node:internal/console/constructor:336:14)
at console.log (node:internal/console/constructor:384:61)
In Node.JS in particular, console.log without formatting can also throw errors on certain values (i.e. throw out of Printer) -- see nodejs/node#60107.