console.log, console.error and other functions with the same purpose shouldn't print undefined in the console even if they return it. When you type these functions in the Console, you don't care about the return value. Furthermore, one can think undefined is the result and be confused.
(In reply to comment #0) > Furthermore, one can think undefined is the result and be confused. This kind of confusion will probably be less likely once bug 19931 is fixed.
> We could add "if (typeof result === "undefined") return;" to match Firebug completely and not print assigned undefineds. I don't think that's a good idea. With this behaviour, one could think nothing happened.
Judging from the behavior of Firebug, it seems to not print any explicit undefineds. >>> undfined >>> var a = undefined >>> (function() { return undefined })(); All do not get printed. Undefineds that are not explicitly assigned get caught in the try/catch and result in an ReferenceError. I kind of feel that doing this is better than having a special case just for console functions. Python console, I think treats "print" differently like that, but that's because print is a keyword.
I think Firebug is wrong on this point. I prefer having undefined all the time, it means "something happened". I understand making a special case for this is sensible. But I think it's good for end users.
I agree that Firebug's "never print undefined as a result" is not a perfect solution. I don't know for sure what a perfect solution is. I do think this bug becomes a lot less important once bug 19931 is fixed.
I think never printing undefined is fine. IMHO, seeing undefined does not tell you anything. Also I think this will be a bigger issues once bug 19931, not less. Since you will see seemingly random undefined values showing up in the middle of the output. But you would also see other return values separated from the original call, which makes it seem like the proposed fix for bug 19931 should not land.
(In reply to comment #6) > I think never printing undefined is fine. IMHO, seeing undefined does not tell > you anything. It tells you "ok, the code was executed". Maybe it's not the best feedback but it's better than nothing i think > Also I think this will be a bigger issues once bug 19931, not less. Since you > will see seemingly random undefined values showing up in the middle of the > output. But you would also see other return values separated from the original > call, which makes it seem like the proposed fix for bug 19931 should not land. I can't see how bug 19931 can change the output. It just prints input before everything. The order between output produced and return value shouldn't change. And I can't understand why it would be random.
(In reply to comment #7) > (In reply to comment #6) > > I think never printing undefined is fine. IMHO, seeing undefined does not tell > > you anything. > It tells you "ok, the code was executed". Maybe it's not the best feedback but > it's better than nothing i think What tells me code executes is I get a blinking caret on a new line and no errors are logged. I don't think we need to log anything unless there is a non-undefined result or there is an error. > > Also I think this will be a bigger issues once bug 19931, not less. Since you > > will see seemingly random undefined values showing up in the middle of the > > output. But you would also see other return values separated from the original > > call, which makes it seem like the proposed fix for bug 19931 should not land. > I can't see how bug 19931 can change the output. It just prints input before > everything. The order between output produced and return value shouldn't > change. And I can't understand why it would be random. It isn't random, but looking at the log it is not clear where the undefined came from (same with any function result if bug 19931 is fixed as proposed.) Look at the screenshot in bug 19931, and you see: > console.log("hi") "hi" undefined That undefined could be a console.log(undefined). The result is not clearly marked.
(In reply to comment #6) > I think never printing undefined is fine. IMHO, seeing undefined does not tell > you anything. I think it's awfully confusing to have nothing print in a case like this: >>> window.undefinedVariable I think the only case where it's arguably better to have nothing print instead of "undefined" is this case: >>> functionThatIKnowReturnsUndefined() I don't think that case is particularly common, except for the console logging functions. Even in this case there's an argument to be made for printing "undefined", since it's consistent with all other cases. > Also I think this will be a bigger issues once bug 19931, not less. Since you > will see seemingly random undefined values showing up in the middle of the > output. But you would also see other return values separated from the original > call, which makes it seem like the proposed fix for bug 19931 should not land. Currently, the order of output you see in the console after evaluating something like "console.log('hi')" is this: 1. Effect of the call ("hi" gets printed) 2. Console input (the command you typed) 3. Return value of the call ("undefined") I don't think that ordering makes much sense. After bug 19931 is fixed, it would be: 1. Console input (the command you typed) 2. Effect of the call ("hi" gets printed) 3. Return value of the call ("undefined") I think this ordering makes a lot more sense, for a couple of reasons: A. The text you typed doesn't appear to move after you press Enter (in the first ordering, stuff gets inserted above the stuff you typed) B. The order of output in the console is the same as the order that things actually happened (first you typed a command, then the command ran, then the command returned)
(In reply to comment #9) > (In reply to comment #6) > > I think never printing undefined is fine. IMHO, seeing undefined does not tell > > you anything. > > I think it's awfully confusing to have nothing print in a case like this: > > >>> window.undefinedVariable > > I think the only case where it's arguably better to have nothing print instead > of "undefined" is this case: > > >>> functionThatIKnowReturnsUndefined() > I agree. Maybe we should detect function calls vs printing a property? > I don't think that case is particularly common, except for the console logging > functions. Even in this case there's an argument to be made for printing > "undefined", since it's consistent with all other cases. Maybe other functions return undefined, any function that doesn't have an explicit return returns undefined. > > Also I think this will be a bigger issues once bug 19931, not less. Since you > > will see seemingly random undefined values showing up in the middle of the > > output. But you would also see other return values separated from the original > > call, which makes it seem like the proposed fix for bug 19931 should not land. > > Currently, the order of output you see in the console after evaluating > something like "console.log('hi')" is this: > > 1. Effect of the call ("hi" gets printed) > 2. Console input (the command you typed) > 3. Return value of the call ("undefined") > > I don't think that ordering makes much sense. Our current order does not make sense. > After bug 19931 is fixed, it would be: > > 1. Console input (the command you typed) > 2. Effect of the call ("hi" gets printed) > 3. Return value of the call ("undefined") > > I think this ordering makes a lot more sense, for a couple of reasons: > > A. The text you typed doesn't appear to move after you press Enter (in the > first ordering, stuff gets inserted above the stuff you typed) > B. The order of output in the console is the same as the order that things > actually happened (first you typed a command, then the command ran, then the > command returned) The main reason I don't like splitting them is the fact we don't visually distinguish the function result from any other console.log output. If we made it visually distinct it would be fine. You do make valid points.
(In reply to comment #10) > (In reply to comment #9) > > I think it's awfully confusing to have nothing print in a case like this: > > > > >>> window.undefinedVariable > > > > I think the only case where it's arguably better to have nothing print instead > > of "undefined" is this case: > > > > >>> functionThatIKnowReturnsUndefined() > > > > I agree. Maybe we should detect function calls vs printing a property? Perhaps. I guess getters would fall under the "property" case? > > I don't think that case is particularly common, except for the console logging > > functions. Even in this case there's an argument to be made for printing > > "undefined", since it's consistent with all other cases. > > Maybe other functions return undefined, any function that doesn't have an > explicit return returns undefined. That's true, returning undefined is pretty common in JS. I'm trying to distinguish between functions where you *know* they will only ever return undefined, and ones where you don't. For the former, printing "undefined" is redundant. For the latter, it isn't. So I just worry that we'd be making things more confusing overall. But maybe I'm not giving our developers enough credit. :-) > The main reason I don't like splitting them is the fact we don't visually > distinguish the function result from any other console.log output. If we made > it visually distinct it would be fine. I agree, we should have a way of grouping the input with the output. I guess we should talk more in bug 19931 about that.
I don't think we need to fix this with my new patch/design attached to bug 19931.