[Webkit-unassigned] [Bug 19932] console functions shouldn't print undefined in the console

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=19932





------- Comment #10 from timothy at hatcher.name  2008-07-08 11:54 PDT -------
(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.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.