Make the Readable constructor handle 'close' events without 'end'. Fixes #478.

[vqvu]

It's possible for a stream to emit close but not end (e.g., when trying to read a non-existant file). We need to end the wrapper stream in that case. Previously, the stream would simply never end.

Ref #478.

[vqvu]

Ok, so it's also possible to only get an error from the Readable. This is what actually happens when reading a non-existent file. The close case is when the user explicitly calls close() or something.

The only way to fix this is to emit nil on our end when we encounter an error. This stack overflow answer seems to suggest that this is the correct behavior.

end

When an error event is fired, the end event will not be fired(explicitly). The emitting of an error event will end the stream.

• http://stackoverflow.com/questions/21771220/error-handling-with-node-js-streams

The only thing that makes me a bit nervous is that the Node docs do not mention anything about the semantics of the error event, and the code will happily allow implementations to call error multiple times. The only exception being the fact that pipe will automatically unpipe all destinations when any destination emits error.

So even though this semantics makes perfect sense to me**, I feel compelled to ask if anyone knows of a readable stream that can emit multiple errors.

** Ironic, since Highland's own error semantics is the opposite.

[vqvu]

Merging this since nobody seems to object.

[jgrund]

Just seeing this now, but I actually have a case of a stream that will emit error but not close/end. I'll open a separate issue.