Improving catch, possibly removing retryWhen

[benlesh]

The proposal is a non-breaking change to catch:

EDIT: see comment below

[benlesh]

cc/ @mattpodwysocki @staltz @trxcllnt for thoughts.

This was something I came up with while reimplementing the retryWhen operator today and discussing @trxcllnt's alternate version of that operator he called retryMany. I realized that both of these could be accomplished with catch if catch simply had a second argument of the source observable. @trxcllnt pointed out that it would have to be the "caught" observable, or really the whatever the last catch call returned, intialized with the source observable. Otherwise on the second catch, it would skip the catch operator all together.

[benlesh]

@zenparsing and @jhusain may find this issue interesting for their es-observable efforts as well, since it's a basic operator.

[benlesh]

So in working with this and talking with George Campbell at Netflix, it seems like the optional arguments should/could be:

myObservable.catch((err:any, source:Observable<T>, caught:Observable<any>) => Observable<any>) => Observable<any>

Where the arguments are as follows:

• error: the error value
• source: the original source observable
• caught: the observable that is the result of the initial source.catch() call

With these arguments one can do just about any type of retry or catch handling. However, it's worth pointing out that any of this could be accomplished with closure as well. It's just that inside of the catch operator, we already have access to all of those observables, so we can easily pass them in without any closure.

I'm torn on this one:

Pros:

• It's a non breaking change to catch
• It adds very little complexity
• It enables retryWhen functionality without an additional operator, and is perhaps easier to explain than retryWhen

Cons:

• While it's probably easier to explain than retryWhen, it's still pretty hard to explain. Like "why return the 'caught' Observable?", etc
• Could do this with closures already.
• ???

I'm sure there are more cons... I'm waiting for others to weigh in.

[benlesh]

To elaborate:

ordinary catch:

myObservable.catch(err => {
  if(isBadError(err)) {
    throw err;
  }
  return Observable.value('something happened, but here is a nice response');
});

retryWhen equivalent:

myObservable.catch((err, source, caught) => {
  if(totallyWannaRetry(err)) {
    return caught;
  } else {
    throw err;
  }
})

[benlesh]

I'm not sure about the utility of the second argument being the source observable... perhaps it should be removed, or moved to be the 3rd argument?