console.assert Node.js behavior

[Fishrock123]

Node.js behaves a bit differently for console.assert() as specified in the docs:

There is even this note: Note: the console.assert() method is implemented differently in Node.js than the console.assert() method available in browsers..

Note: console.assert() was added in Node v0.1.101. Changing it may be difficult.

[jsinmotion]

C assert usually ends in a program abort when the assertion is false. I assume that's why node's console.assert throws an error. Popular JS assertion libraries like https://github.com/shouldjs/should.js also interpret assertions to be errors. IMHO Chrome and currently specced console.assert behavior is not consistent with common use of the name assert.

I would vote to standardize on the node interpretation and change the name of the existing warn-if-false behavior to something else.

[domenic]

That's not really an option; it would start breaking lots of websites deployed in the world as the code after their asserts would stop working.

This is another 4 vs. 1 scenario where it is best for Node to just update. They can be in violation if they want; they seem to have a note indicating that it's intentional. But that just means it's impossible to write portable code between the other 4 implementations and Node if you use console.assert.

It's especially amusing because Node actually has an assert library that makes its error-throwing behavior redundant, where the browser does not.

[jsinmotion]

If you have experience with a programming language C or python that has asserts, you don't really expect code after an assert to run if the assertion fails. The name "assert" as it is used in many other programming languages doesn't really match with the specced behavior IMHO.

[JosephPecoraro]

Merely searching "disable assert" immediately shows that defining NDEBUG in a C environment will disable the typical assert() provided by assert.h. Likewise searching "disable assert python" gives me a solution there.

I have always viewed assertions as debugging capabilities able to be turned on or off. In the browser environment not having developer tools connected would be akin to having assertions disabled. I don't see this as unorthodox.

[jsinmotion]

@JosephPecoraro If you really want to go down the rabbit hole, the analogue to what you are referring to is a "release build" which you would implement as a build step like minifying your JS files. the assert macro is noop'd when you define NDEBUG in your build. That actually leads to really subtle differences when you deal with side effects in assertions themselves.

For example, take the following javascript code:

var i = 1;
console.assert(--i)
console.log(i)

and the equivalent C code:

int i;
i = 1;
assert(--i);
printf("%d\n", i);

What is printed in each case?

• node will throw an AssertionError

• C compiled without the NDEBUG flag will abort

• C with the NDEBUG flag will print 1 (since the entire statement is not evaluated, the side effect of decrementing i isn't triggered)

• chrome will print 0 (the statement is evaluated, including the side effect)

Notice how the browser does something different from C. What the browser is doing doesn't really parallel assert as it is commonly understood and IMHO is a truly unfortunate name.

[JosephPecoraro]

I considered mentioning this macro behavior but I figured it wouldn't be productive. I think the more important higher level behavior is the ability to turn on or off assertions, not so much the ability of a macro to skip code completely. Maybe others would disagree?

JavaScript does not have macros, or the ability to "skip code" in this way. I don't think Console APIs would be right place to enable such a feature; if it was I suspect it could be abused. The topic of side effects has come up before #54 (comment) and I don't think this spec and its contributors have arrived at conclusion to the side effect question yet.

Finally, if authors really wanted to avoid the expressions in console.assert calls they could always strip them out of the code in a post/pre process of their source. In fact, that is what we do in WebKit with our JavaScript source containing assertions.

[jsinmotion]

My point was that the current browser behavior is not really consistent with any other language that use assert. C has the two behaviors depending on the compiler flag, python throws an error, java does something at runtime that roughly approximates C (iirc it noops the condition if -ea isn't passed), php provides a string-based workaround to avoid evaluating the condition.

And yes, people can perform magic to address the deficiencies, but it is just truly unfortunate that the browsers settled on this behavior for console.assert. IMHO node's behavior in this regard more closely matches the spirit of other programming communities and their understanding of assert.

[terinjokes]

Thanks, @jsinmotion, @JosephPecoraro, and @domenic for these valid points. It's unfortunate that we've evolved two incompatible implementations and that changing either environment would be a breaking change.

For reasons dating back to the days of yore, I don't expect Node.js to change, as they attempt to match well-established behavior. At the same time, I don't expect browser vendors will want to break sites by introducing exceptions.

In my personal opinion†, I would opt for acknowledging the difference, as the Node.js documentation and MDN have already done, then investigate adding a replacement—even though we've burned the best name—that both environments can unify on.

I've inherited this decision, so, mostly for curiosity, I'd love to know why browsers implemented assert this way.

---

†: As just some guy who occasionally writes JavaScript in Node.js and the browser.

[JosephPecoraro]

I suspect this is everyone just followed Firebug's original implementation, which was the canonical console implementation at the time. WebKit (and therefore Blink) added console.assert back in 2008 basing its implementation off of Firebug.

---

Not speaking as an implementor but just as a user here.

JavaScript had a debugger reserved word since version 1 in 1997. It wasn't described as having behavior until ES5 much later on. The debugger statement currently reads as (emphasis mine):

Evaluating the DebuggerStatement production may allow an implementation to cause a breakpoint when run under a debugger. If a debugger is not present or active this statement has no observable effect.

I've always had the impression that Console APIs behave in the same way, by doing as little as possible, or perhaps nothing at all, unless a debugger was present / active. I was not involved enough back then to know, but I wouldn't be surprised if this was also influenced by Firebug. Having console.assert not do anything if a debugger was not active also seems to fit that pattern.

[jsinmotion]

@JosephPecoraro Thanks for the background! This is a really strange story.

According to Firebug https://getfirebug.com/wiki/index.php/Console.assert should throw an error (last edit was in 2013):

Tests whether an expression is true. If not, it will write a message to the console and throw an exception

Now, it's possible the source documentation is wrong. I only started working with JS recently and I do not have a copy of firebug to verify. But that's the official site. If the firebug documentation is correct, and if we interpret "We should support Firebug's console.assert method." from the commit message to mean "replicating Firebug's console.assert", then why doesn't the patch throw an error?

Turns out, there's a funny email from the mailing list: https://groups.google.com/forum/#!searchin/firebug/console.assert()$20does$20not$20throw$20exception%7Csort:relevance/firebug/ZrdRZA8fxDE/g0TcvEuFmPwJ

Hi,
console.assert() does not throw any exception. The red message is
displayed, but execution is continued on the next statement. This
behavior is in contradiction to the manual, isn't it?
Kind regards, *****

What does this mean? I think the timeline looks like this:

1. When the feature was first specced out in Firebug, console.assert was supposed to throw an error if the assertion was not true. This is consistent with other major programming languages that had the assert feature

2. There was a bug in Firebug! The documentation claimed it should throw an error but the implementation did not

3. when the feature was copied to webkit, console.assert mimicked the actual Firebug implementation, essentially replicating the bug. The author probably didn't consult the documentation and that would explain why he or she didn't bring up this question at the time.

4. Other browsers copied webkit's implementation, continuing to propagate the bug. Again, my guess is that no one looked at the firebug documentation when copying the feature.

5. Node ended up implementing a console.assert that was in-line with other major programming languages that have assert. No surprise, it aligned with the intended Firebug implementation.

So the mess right now basically boils down to a propagation of a very old bug in Firebug. Given that the original intent of Firebug lines up with "well-established behavior", I think we should fix the bug and adopt the approach of console.assert throwing an error.

[MylesBorins]

So it seams to me that we have an issue where both environments are going to have too much legacy code to really break this.

Could we potentially extend the spec? Make an optional third argument to allow the user to decide if it should throw. If not provided use default behavior of runtime.

This would allow the current behavior to remain unbroken, but give developers the ability to be explicit and make portable code

I am digging into the spec and seeing that the second argument ..data is fairly ambiguous. That essentially gets passed to Logger, which in turn is able to parse ..data and determines if the first argument is a format specifier. It would seem that we should be able to use a similar tactic to pass a specifier regarding throwing to assert, but I'm not sure of prior art or if this is a terrible idea for reasons I have yet to think of.

Am I on the right path?

[domenic]

Unfortunately I don't think so. The purpose of the spec is to help achieve interop, i.e. code that works the same in all places. Otherwise we might as well not write a spec at all. We're already at 4/5 environments behaving the same, so we've made significant progress there. We should just stay the course. Adding a third argument does not help interop in the 2-arg case (and is implemented in 0/5 environments).

[ethanresnick]

Casual observer here, but it seems like the first step would be to try to measure how much breakage there'd actually be from changing node's (or, possibly maybe, the browser's) behavior. Without knowing that, it seems hard to know whether @domenic's position to break Node is tenable. If change on either side would be too much breakage, I like @terinjokes or @MylesBorins's idea of adding a new, portable API in some form or another.

[jsinmotion]

@ethanresnick I originally thought there was room for alignment of browser console and node console but nodejs/node#10292 (comment) gave me a different perspective on the matter:

console.log() in browsers is a debug tool for sticking messages in debug window that is viewable ONLY by developers.

console.log() in node is a way of printing to the terminal, the actual user, or to whever the stdout has been directed.

To generalize, there's a perspective that console in the browser is strictly a debugging tool whereas console in node takes on a more significant purpose. From that view it actually makes no sense to try to align the behaviors.

In this particular case, the node console.assert is intended to mirror assert in other programming languages, which makes perfect sense from the view of a developer. In non-browser environments, a failed assertion results in an error/exception as appropriate. The browsers take the view that console is strictly for the developer, and as such console.assert should be innocuous. There's no way to align behaviors without reconciling the differences between the two views of what "console" really is. Using console.log to display non-debugging information is a somewhat common practice in node, so I don't see the node view changing. And since non-developers generally don't have the console open, I don't see the browser developers changing either.