EPIPE errors thrown when piping to a closed stream

[bilalq]

So this issue seems to have been around for quite some time. The problem
probably affects all instances where things are piped into closed streams, but a
very common example that comes up in practice is piping the output of a node
program to something else.

Let's use this as a simple example:

$ node -e 'console.log(1);console.log(2) | cat'
1
2

When piping to something that won't consume the entirety of the stream, the
program crashes in a very unhelpful way:

$ node -e 'console.log(1);console.log(2)' | head -1
1

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: write EPIPE
    at errnoException (net.js:905:11)
    at Object.afterWrite (net.js:721:19)

Categorizing this as an error in the first place is a little strange. While I
can appreciate that trying to write to a closed stream is an error in theory,
it seems really odd to crash like this when not paging through everything on
stdout.

Treating stdout as a special case may be a bit much to ask, but at the
very least, there should be some improvements to the error messaging here. The
example I gave was just using node -e, but even with a proper file, no useful
stacktrace or messaging is provided. Maybe add something like:
Warning: Attempting to pipe to a closed stream (foo.js:10:12)?

I discovered this as I was piping the output of a CLI program I'd written to
less. When paging all the way to the bottom, no errors would be logged, but
exiting less before paging all the way through would consistently have the EPIPE
error written to stderr.

Right now, there are a few workarounds.

Users can just redirect stderr to /dev/null like so:

$ 2>/dev/null node -e 'console.log(1);console.log(2)' | head -1
1

or use the epipebomb module.

Neither approach is ideal.

[pmneve]

I was running into this issue intermittently and epipebomb solved the problem.
Agreed it is not ideal.

[jasnell]

Can confirm the behavior exists in the latest io.js as well.

[jasnell]

Looking it over, this and #6694 are likely the same basic issue.

[Fishrock123]

Issue on the io.js tracker: nodejs/node#947

[Fishrock123]

Looks like Ben said it was (possibly?) related to nodejs/node#831

[brendanashworth]

I'm going to close this in favor of nodejs/node#947.