"flatCatchMap"

Doing error handling with flatMap is a little annoying, because you have to turn .flatMap(i => promisy()) into .flatMap(i => Rx.Observable.from(promisy()).catch(e => ["substitute busted items"])).

It’d be nice if we had something like flatCatchMap (name totally negotiable), which would accept a projection to transform values into observable-likes, and another projection to transform errors into observable-likes.

[benlesh]

Honestly, most of the time you want to compose the error handling into the observable inside of your flattening operator:

source.flatMap(() => from(promisey()).catch(err => empty()))

And maybe you want retry or retryWhen or maybe you just want to let it die and handle it further down the pipe.

I don’t think the community has an appetite to add another operator at this time… but you can easily cook your own pipeable operator now:

const flatCatchMap = (project, errorHandler) => source => source.pipe(
  flatMap(project),
  catchError(errorHandler),
);

[masaeedu]

The problem here is that flatMap is about as fundamental an operator as you can get, and in 90% of projects that’s the only one I really use (most other things you can implement on top of that). If I’m flatMapping over 10 levels of asynchronicity or many-ness and keep having to do .catch(e => ["failed"]) to propagate errors down the chain, the code becomes really unwieldy and verbose.

There’s a proposal in #2929 for removing resultSelector from flatMap, I think the newly freed up second argument would be a good place for an error selector.

I could write my own operator as you said, but I’d have to package it, distribute it, manage compatibility and versioning, add an extra dep in each project, etc.