Clarify the return values of the methods

[SebastianZ]

There was a question on Stack Overflow regarding the return value of the console.log() function within Firebug. This is obviously unintended and will be changed in issue 7774 to return undefined.

It should be clarified that the console object methods are not expected to have any return value.

Sebastian

[paulirish]

+1. I use console.log() in conditional breakpoints and rely on the fact that return value is undefined. sounds good to clarify that.

[fflorent]

It should be clarified that the console object methods are not expected to have any return value.

I am not personally exited by this idea. Newcomers in the JS world may wonder why console.log() actually prints two results.

That's just my two cents.

Florent

[bkardell]

@fflorent why would this impact what anyone sees or how would it impact newcomers? Example? I'm not understanding somehow.

[fflorent]

The fact is that if we return undefined, that would be printed in the console, just as the Firefox and Chrome DevTools do:

Firebug used not to print undefined by returning some arbitrary value that is ignored in the console.

And I fear that printing undefined may be unclear to the newcomers to the "JS world". But I can't tell that anymore, since I am not anymore in that situation.

That's the reason why I said I was not "existed" about this idea (though not against). What would be neat would be to get the reaction of a newcomer when they notice the undefined value being printed (and how "strong" is their reaction to this).

(hope that's clearer)

Florent

[bkardell]

@fflorent in JavaScript, functions must have return values even if that is undefined and the way the console works is to evaluate and return/print the result - it seems to me the issue you have is with the devtools doing both, not that there -is- a return value. I dont see a better option as if it returns something arbitrary like "OMGTHISISARBITRARY!@#!@$" that would print too.... Any return value would be printed by devtools, right? Other than special-casing something that only does console.log in the devtools to not also print the result of evaluating, I'm not really sure what else you could do? Either way, it doesnt seem like the domain of the console api to me?

[past]

I was among those who argued in favor of displaying the return value of undefined in the Firefox devtools, because I believe it educates more than it might confuse. console.log() should be no more magic in my view than, say, window.alert(). We should restrict any magic behavior to console helper functions that are part of the tool and not part of the web.

[andysterland]

Over in IE and Visual Studio land we try to ensure that console.* always returns undefined to the page. Partly because the idea is that the console object shouldn't impact the state of the application as it's meant for debugging info only.

UI wise we're always debating about to show or not show undefined. Currently we show it always because at the end of the day it is the return value. It does look wonky in some situations for example when developers are using the console to define new (global) functions. I think in the future we'll add a UI option to let the developer choose to show undefined or not.

But, I do think that the high order bit is to be consistent with what is returned to the page. UI wise tools should decided what's best for them but the experience from code on the page should be consistent.

[SebastianZ]

Note that the main point I opened this issue was to say that it should be stated that the console functions have undefined as return value (and not something else as in Firebug up to version 2.0.8).

Whether or not the return value is displayed within the tools may not be part of this project.

(FWIW I agree with @past that the return value should be displayed for the same reason.)

[fflorent]

@fflorent in JavaScript, functions must have return values even if that is undefined and the way the console works is to evaluate and return/print the result

Yes, I know that pretty well ^^.

Whether or not the return value is displayed within the tools may not be part of this project.

True in retrospection. Sorry for having deviated the debate. We're discussing about what should return an API and not what/how it should display the logs through the command line.

Anyway, I tend to agree it should return undefined because that's what we expect from the exposed Console API. Moreover, workarounds could operate not to display the return value in the Console (if the implementors decide so), but they should not confuse the users (as the one in Firebug visibly currently does).

Florent

[bkardell]

@fflorent yeah, sorry I wasn't intending to imply you didn't know that (I know you do) - I was just pointing it out so as to highlight the issue isn't likely in the return but in the tool.

[fflorent]

@fflorent https://github.com/fflorent yeah, sorry I wasn't intending
you didn't know that (I know you do) - I was just pointing it out so as
to highlight the issue isn't likely in the return but in the tool.

No worry :).

Florent