Rxjs: I loved VB, really. But onErrorResumeNext might be the worst name ever.

[benlesh]

My issue with the name

1. RIght now we have two things named onErrorResumeNext: An observable creation function and an operator.
2. To stick with convention, the operator should be renamed to onErrorResumeNextWith... which is _ridiculously long_.
3. Generally the trade-off for a long function name is that it is highly descriptive and tells you exactly what that function does, however, in this case, I feel like it does not at all tell the developer what it does.
   3 "On Error, Resume Next" sounds like it is going to go to the next one, but ONLY if there's an error. Someone would have to have been a VB6 developer to really know what the implication here is, and being that I was on the tail end of that, and I'm a dinosaur, I have to think most people nowadays have no idea where it even came from.

Re-evaluating The Name

Really, what it does is concat, only ignoring errors. Maybe it should be called like: concatRegardless haha. Or failoverConcat or concatAlways or... something else?

Note that it must work with the staticName and staticNameWith convention. (e.g. concat and concatWith, et al)

Also note that this is a _RE-EVALUATION_ of the name. We may well decide to keep it the same. However, in my experience, this bit of functionality isn't the most popular feature of RxJS, so it seems like a deprecation and rename would be low-impact.

[niklas-wortmann]

One thing to consider though is that many of the other Rx* implementation have an onErrorResumeNext.

I liked the use of concat though, what about concatError?

[cartant]

FWIW, my revulsion of VB is the reason I've never seriously entertained using the onErrorResumeNext operator.

[jgbpercy]

concatAlways seems like a very good name to me, as long as the behavior is actually consistent with concat, except treating errors as completes - adopting that name would definitely introduce that expectation, so if there are other subtle (or not so subtle) differences between the two then they should probably be addressed, or a different name found.

[paulpdaniels]

Devil's advocate, Does it really need to be one operator? Couldn't it just be: source.pipe(ignoreErrors(), concat(other)), that way the implication is explicit, and the api surface area decreases? Like was mentioned this doesn't have a lot of usage to begin with which means people are probably already writing this pattern if they need it.

[Zcating]

why not name serial & serialWith.

const source1 = throwError(new Error('test'));
const source2 = of(1)
serial(source1, source2).subscribe((value) => console.log(value));
// [Error: test, 1]

[benlesh]

Core Team Meeting: We should just mark onErrorResumeNext for deprecation, since it's weird, and easy to replicate with existing concat and catchError. According to our collected statistics it's used very, very little.