there's a way to handle errors with forkJoin
that doesn't block you from using this operator. The key is actually part of the other answer.
Yes, forkJoin
will complete on first error and you kinda can't know from which observable it came, but if you handle errors inside the inner observables you can easily achieve that.
Consider this (minified) part of your code, mixed with @Explosion Pills answer:
reqs: Observable<any>[] = [];
if (shouldUpdatePhone) {
reqs.push(
this.service.updatePhone(phone)
.pipe(
catchError((err) => {
// Handle specific error for this call
return of(undefined)),
}
)
);
}
if (shouldUpdateAddress) {
reqs.push(
this.service.updateAddress(address)
.pipe(
catchError((err) => {
// Handle specific error for this call
return of(undefined)),
}
)
);
}
And then, for your forkJoin
:
forkJoin(reqs).subscribe(result => console.log(result));
Now consider that both API calls return an object like, respectively, {phone: string}
and {address: string}
. Your result
will be:
[{phone: '123-456'}, {address: 'Happy Street, 123'}]
But ok, that's basic forkJoin
, where's the error handling part?
Consider that one of your calls failed, the returned error contains a status code and a message and you want to know 'em both.
As I said, forkJoin
won't complete if you handle error inside the inner observable, that's why we have
.pipe(
catchError((err) => {
// Handle specific error for this call
return of(undefined)),
}
)
If your first call (updatePhone) fails, your result would be
[undefined, {address: 'Happy Street, 123'}]
Because you didn't let the observable die and, upon error, returned a new Observable with return of(undefined)
.
This opens you the possibility to handle errors like this (inside catchError
):
catchError((err) => {
if (err.status === 409) {
// do something
}
return of(undefined)),
}
Or like this
...
catchError((err) => {
return of({error: err, isError: true})),
}
...
forkJoin(...).subscribe(result => {
result.forEach(r => {
if (r.isError) {
// do something
}
});
});
All your API calls will complete and you can either handle it on the go or wait for all of them to return and handle only the ones that returned error, with this you can get any information that your error could provide to you and handle it specifically.