cleanup: consider splitting "complete" vs "error"

[bakkot]

Right now there is a proposed finally which is called regardless of how the observable is closed.

Web streams split this into two hooks: one called on normal exit, one called on error. (There is an old issue suggesting a finally, but there's no movement on it.)

It may be desirable to match web streams. Or it may not. I moderately prefer a single hook personally, although in some scenarios it's nice to know which kind of exit this was.

[benlesh]

@bakkot this is more akin to finally() on a promise. The use case is clean up of things you may have started during observation or via side-effects from within different methods. If I'm understanding this request, it's around a desire to fire a callback if the stream is aborted or unsubscribed by the consumer. In practice, finally (or finalize in RxJS) is only sometimes used to "know" when someone has aborted/unsubscribed from the stream — and even then, it's usually not a good pattern. The only valid use case I could think of to want to know when the consumer unsubscribed specifically would be for some sort of verbose logging.

[domfarolino]

If I'm understanding this request, it's around a desire to fire a callback if the stream is aborted or unsubscribed by the consumer.

This doesn't sound correct, right? The original concern sounds producer-focused, to provide a way to detect error() vs complete() from the producer. Not about separating out whether the consumer did anything.

In general though, I do agree with the Promise finally() analogy, and wonder what the efficacy of splitting the two would be.

[domfarolino]

I just want to check in on this thread after #49 has landed. @bakkot what do you think of the some of the comments above? Did they clear up the utility for finally(), to you?

[bakkot]

It's less that I was unsure about the utility and more that I wanted to raise the possibility of aligning with the precedent in web streams, which are similar in some ways. If that alignment isn't worth it, that's fine.

[domfarolino]

I see. It's tricky because it seems like there's precedent set by both streams (splitting the hooks, as you mentioned), and also Promises (with Promise.prototype.finally()). I hope the alignment with Promises won't be too confusing for people though.