Send non-JS output (e.g. errors) to stderr, instead of stdout.

Send non-JS output (e.g. errors) to stderr, instead of stdout.

The Chromium build uses this executable and needs to be able to
separate errors from JS output.

Committed: https://code.google.com/p/v8/source/detail?r=12941

[Patrick Dubroy, 2012-11-12 18:15:42]

Please take a look.

[Sven Panne, 2012-11-13 08:02:04]

Hmmm, I thought that Chromium uses d8 now and shell.cc is now what it was
actually meant to be: A trivial example how to embed v8. I don't think we have
any test coverage for shell anymore.

[Yang, 2012-11-13 08:48:16]

Some comments.

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc
File samples/shell.cc (right):

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode253
samples/shell.cc:253: fprintf(stderr, "V8 version %s [sample shell]\n",
v8::V8::GetVersion());
This is the prompt of the interactive shell and must not go to stderr.

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode260
samples/shell.cc:260: fprintf(stderr, "> ");
Ditto.

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode266
samples/shell.cc:266: fprintf(stderr, "\n");
Ditto.

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode314
samples/shell.cc:314: fprintf(stderr, "%s\n", exception_string);
This reports uncaught exceptions caused in javascript. I think the policy should
be that error messages caused in this shell (like failed read of a file) should
go to stderr and error messages of the javascript runtime should go to stdout.
Same goes for all the output in this function.

[Patrick Dubroy, 2012-11-13 09:56:24]

On 2012/11/13 08:02:04, Sven Panne wrote:
> Hmmm, I thought that Chromium uses d8 now and shell.cc is now what it was
> actually meant to be: A trivial example how to embed v8. I don't think we have
> any test coverage for shell anymore.

out/Debug/v8_shell in Chromium is built from shell.cc.

[Patrick Dubroy, 2012-11-13 09:56:28]

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc
File samples/shell.cc (right):

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode253
samples/shell.cc:253: fprintf(stderr, "V8 version %s [sample shell]\n",
v8::V8::GetVersion());
On 2012/11/13 08:48:17, Yang wrote:
> This is the prompt of the interactive shell and must not go to stderr.

I thought I mentioned this yesterday, but that is the way that Python does it.

    ~/dev/chromium/src$ python > /tmp/python-output
    Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
    [GCC 4.6.3] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> def a():
    ...     print 3
    ... 
    >>> a()
    >>> 
    ~/dev/chromium/src$ cat /tmp/python-output 
    3

It seems reasonable to me, but I can change that if you'd like.

https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode314
samples/shell.cc:314: fprintf(stderr, "%s\n", exception_string);
On 2012/11/13 08:48:17, Yang wrote:
> This reports uncaught exceptions caused in javascript. I think the policy
should
> be that error messages caused in this shell (like failed read of a file)
should
> go to stderr and error messages of the javascript runtime should go to stdout.
> Same goes for all the output in this function.

I disagree. An uncaught exception needs to be logged to stderr, not stdout.  

In the Chromium build use case, we have a script that generates a C++ class by
printing it to stdout, so we capture stdout from the script and send it to a
file. If uncaught exceptions aren't printed to stderr, we have no way of
actually extracting the error message.

Python and Ruby also send messages from uncaught exceptions to stderr:

    ~/dev/chromium/src$ python -c "raise Exception" > /dev/null
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    Exception

    ~/dev/chromium/src$ ruby -e "raise 'blah'" > /dev/null
    -e:1: blah (RuntimeError)

[Yang, 2012-11-13 10:29:17]

On 2012/11/13 09:56:28, dubroy wrote:
> https://codereview.chromium.org/11365202/diff/1/samples/shell.cc
> File samples/shell.cc (right):
> 
> https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode253
> samples/shell.cc:253: fprintf(stderr, "V8 version %s [sample shell]\n",
> v8::V8::GetVersion());
> On 2012/11/13 08:48:17, Yang wrote:
> > This is the prompt of the interactive shell and must not go to stderr.
> 
> I thought I mentioned this yesterday, but that is the way that Python does it.
> 
>     ~/dev/chromium/src$ python > /tmp/python-output
>     Python 2.7.3 (default, Aug  1 2012, 05:14:39) 
>     [GCC 4.6.3] on linux2
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> def a():
>     ...     print 3
>     ... 
>     >>> a()
>     >>> 
>     ~/dev/chromium/src$ cat /tmp/python-output 
>     3
> 
> It seems reasonable to me, but I can change that if you'd like.
> 
> https://codereview.chromium.org/11365202/diff/1/samples/shell.cc#newcode314
> samples/shell.cc:314: fprintf(stderr, "%s\n", exception_string);
> On 2012/11/13 08:48:17, Yang wrote:
> > This reports uncaught exceptions caused in javascript. I think the policy
> should
> > be that error messages caused in this shell (like failed read of a file)
> should
> > go to stderr and error messages of the javascript runtime should go to
stdout.
> > Same goes for all the output in this function.
> 
> I disagree. An uncaught exception needs to be logged to stderr, not stdout.  
> 
> In the Chromium build use case, we have a script that generates a C++ class by
> printing it to stdout, so we capture stdout from the script and send it to a
> file. If uncaught exceptions aren't printed to stderr, we have no way of
> actually extracting the error message.
> 
> Python and Ruby also send messages from uncaught exceptions to stderr:
> 
>     ~/dev/chromium/src$ python -c "raise Exception" > /dev/null
>     Traceback (most recent call last):
>       File "<string>", line 1, in <module>
>     Exception
> 
>     ~/dev/chromium/src$ ruby -e "raise 'blah'" > /dev/null
>     -e:1: blah (RuntimeError)

I see. LGTM then. I'll land this for you.