Error handling is unspecified

[Fayti1703]

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: https://github.com/whatwg/console/blob/6f299db3a4ca5abc00320e570077ffdfca85f66f/index.bs#L334-L335 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.

[nchevobbe]

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1992350 for Firefox, we should definitely report the error.

[nchevobbe]

Note that for console.log("-->%s<--", { toString() { throw new Error("nope") } })

• Safari prints -->Object<--
• Deno propagates the error
• Bun propagates the error