From the perspective of the top-level API, abort() errors behave inconsistently

[MattiasMartens]

Imported from #47

In the case where abort() is not caught inside a utility function, an error passed to abort() has to be handled at the source, or it will bubble up as an unhandled rejection. An unhandled rejection generally signals to the developer that they've done something quite wrong (Node will of course scold you severely for doing this!). And according to the Stream idiom, they have.

In the case where abort() is caught inside a utility function (to pass it downstream), an error passed to abort() won't bubble upstream to the source, even though the "handling" that's taking place is trivial and not actually doing anything. In this case, an abort() error will simply be swallowed, and the developer won't see it so they won't be under the impression that they've handled anything incorrectly.

Technically, they really haven't, because swallowing an abort error is a valid response to it. But it is a surprising experience for the developer. It's one thing to have an error bubble up and not understand why—then at least there's something to understand. It's another to have an error get swallowed by the internal implementation before the developer can even learn about it.

[poelstra]

As commented in #47:

True. This is tricky, and I don't have a direct answer/solution here. It's always going to be a heuristic of course (like Node's eventEmitter.emit("error") stuff too), but I agree that if we can improve things for the most common cases, it would definitely help.
I suppose we need to take this into account in the discussion at #24 too.