console.assert(false, Symbol()) throws #49680

Activity

1. bnoordhuis commented on Sep 17, 2023

   

   bnoordhuis

   on Sep 17, 2023

   Member

   More actions

   Working as expected/documented. Try this instead:

   console.assert(false, "%o", { hello: "world" })
   // or even just:
   console.assert(false, "", { hello: "world" })

   It wouldn't be hard to use util.inspect() by default but:

   1. it's the documented behavior
   2. is mandated by the console spec
   3. would be a rather visible change (can spam large amounts of text to the console) and therefore at least a semver-major change

   You're welcome to open a pull request and see how it's received if you still think it's a good idea but be prepared for rejection.
2. bnoordhuis

   closed this as not plannedon Sep 17, 2023
3. bnoordhuis

   added

   consoleIssues and PRs related to the console subsystem.Issues and PRs related to the console subsystem.

   on Sep 17, 2023
4. jcbhmr commented on Sep 17, 2023

   

   jcbhmr

   on Sep 17, 2023 · Hidden as outdated

   Last edited by jcbhmr

   Author

   show commentMore actions
5. bnoordhuis commented on Sep 17, 2023

   

   bnoordhuis

   on Sep 17, 2023

   Member

   More actions

   Yes, I'm pretty sure. The more human-readable prose from the MDN lemma (emphasis mine):

   A list of JavaScript objects to output. The string representations of each of these objects are appended together in the order listed and output.

   It's only when you use a message format string that object formatting comes into play:

   JavaScript objects with which to replace substitution strings within msg.
6. jcbhmr commented on Sep 19, 2023

   

   jcbhmr

   on Sep 19, 2023

   Last edited by jcbhmr

   ContributorAuthor

   More actions

   After further investigation, here's the erroneous line:
   

   node/lib/internal/console/constructor.js

   Line 435 in cd97e28

   args[0] = `Assertion failed${args.length === 0 ? '' : `: ${args[0]}`}`;

   👆 this isn't precisely spec compliant. Why? Because there's supposed to be this:
   

   which means something more like this:

     assert(expression, ...args) {
       if (!expression) {
         if (typeof args[0] === "string") {
           // if you provide a fmt string, it still gets used (first arg)
           args[0] = `Assertion failed: ${args[0]}`
         } else {
           // but if it's anything else, it's not stringified as a format string;
           // its just an object to be printed. so we prepend a fmt string arg (with no specifiers
           // that would eat any user-supplied objects) as a nice "Assertion failed" message
           ArrayPrototypeUnshift(args, "Assertion failed")
         }
         // The arguments will be formatted in warn() again
         ReflectApply(this.warn, this, args);
       }
     },

   you can see a bug here from the current Node.js impl that highlights what's happening:

   const mySymbol = Symbol()
   console.assert(false, mySymbol)
   // THROWS because Symbol() cant be stringified like `symbol string: ${Symbol()}`!

   the mdn thing you cited:

   A list of JavaScript objects to output. The string representations of each of these objects are appended together in the order listed and output.

   this same language "string representations" is also used in console.info() and other console methods to mean the formatted pretty output not the .toString() version:
   https://developer.mozilla.org/en-US/docs/Web/API/console/info
   

   also backed up by someone from the whatwg/console repo:

   My understanding of the spec is the object {hello: "world"} would get passed as a member of args (eg, ["Assertion failed", {hello: "world"}]) to Printer, which is implementation defined. Converting a POJO to the string "[object Object]" is certainly a valid way of being implementation defined, but I wouldn't judge it "to be maximally useful and informative."

   whatwg/console#226 (comment)

   so in summary it would seem:

   • [object Object] is a valid string representation of the object
   • ...but it's not very helpful
   • there's the edge case with Symbol() not being stringifiable in the way console.assert() is implemented
   • most other runtimes Chrome/Firefox/Deno/Bun do it where console.assert(false, {a:1}) is properly inspected; Node.js is the outlier.

   i also am making an effort to clarify the mdn wording that had us all confused 🤣 mdn/content#29172
7. jcbhmr

   changed the title [-]`console.assert(false, { hello: "world" })` logs `[object Object]` instead of inspecting the object[/-] [+]`console.assert(false, Symbol())` throws[/+] on Sep 19, 2023
8. jcbhmr commented on Sep 19, 2023

   

   jcbhmr

   on Sep 19, 2023

   ContributorAuthor

   More actions

   Changed title and body to reflect exact buggy impl:

   console.assert(false, Symbol())
9. jcbhmr

   added a commit that references this issue on Sep 19, 2023

   console: treat non-strings as separate argument in console.assert()

   ...

   This issue will close once commit 9ac6528 is merged into the 'main' branch.

   9ac6528
10. BridgeAR commented on Sep 19, 2023

    

    BridgeAR

    on Sep 19, 2023

    Member

    More actions

    @bnoordhuis I believe it's fine to handle it that way. It aligns well with the other APIs where the object would be printed in a human readable way. There's also already an open PR and I guess we could reopen the issue as such?
11. bnoordhuis commented on Sep 20, 2023

    

    bnoordhuis

    on Sep 20, 2023

    Member

    More actions

    Yeah, I'm fine with that, I don't really have a strong opinion either way except that changing the default should be a semver-major change.

    👍React with 👍1Reacted by Yagiz Nizipli
12. bnoordhuis

    reopened this on Sep 20, 2023
13. nodejs-github-bot

    closed this as completedin #49722on Nov 1, 2023
14. nodejs-github-bot

    added a commit that references this issue on Nov 1, 2023

    console: treat non-strings as separate argument in console.assert()

    ...

    This issue will close once commit 60e8364 is merged into the 'main' branch.

    60e8364