Javascript 在处理错误之前检查中间Rxjs结果

我正在使用Observables来处理Angular中的HTTP请求，对于错误处理有一个问题。所讨论的端点根据操作的成功程度返回布尔值。但是，

false

值（据我所知）不会触发错误处理程序

以下是一个例子：

this.myService.myMethod(user.id)
    .subscribe(
        result => {
            if (result) {
                // ... do some things
                return;
            }
            
            // result is false here, so I want to trigger the error handler
            return throwError({});
        },
        error => {
            // handle the error
            // I want this to happen for non-200 responses and 200 responses with a false result
        }
    )
);

---

这是处理此类错误的最实用的方法吗？我已经尝试了上述方法，我注意到在

throwerr

上没有触发错误处理程序。

我强烈建议您避免在

subscribe

回调中放入任何逻辑，并将所有内容放入

管道中。至于方法，我建议如下：

this.myService.myMethod（user.id）.pipe(
mergeMap（result=>result？of（result）：throwError（'My error！'）），
点击（结果=>doStuff（）），
catchError（错误=>{
handleError（错误）；
返回空；
}
)
).subscribe（）；
您可以使用
点击
抛出错误。此错误将被捕获并作为错误通知传播

this.myService.myMethod（user.id）.pipe(
点击（结果=>{
如果（！result）抛出结果
})
).订阅(
结果=>{
//做一些事情
},
错误=>{
//处理错误
}
);
对于HTTP请求，200不是错误。如果在这两种情况下都应该发生相同的错误处理（带false的200或非200），那么我建议将该错误处理提取到另一个方法中，并从两个位置调用该方法。我的意思是，我希望我编写的逻辑能够触发错误处理程序，即使响应是200（但数据是假的）。对，但我想说的是，你正在试图向逻辑中注入一个错误，以使其他逻辑发生，而不是仅仅调用所需的逻辑，如果它是一个提取的方法，你可以这样做。我不认为以这种方式抛出异常有什么错，但我建议将逻辑放在
管道中，而不是回调
订阅
。我正在整理答案。通常最好避免在订阅回调中加入逻辑。将所有内容都保存在管道中会使内容更易于阅读和维护。这取决于您所做的工作。在我看来，用
o$.pipe（tap（v=>doStuff（v））.subscribe（）代替
o$.subscribe（v=>doStuff（v））
是毫无意义的。但是将错误处理移到
this.myService.myMethod
中是可取的。为了在整个应用程序中保持代码风格，最好的做法是将所有内容都放到管道中。这样，当有一天你必须添加功能时，你不必重构所有东西。此外，通常最好分散错误处理以保持代码整洁，因此将其放在服务方法中通常不是最佳选择。@WillAlexander分散错误处理如何保持代码整洁？你只会在整个应用程序中重复相同或类似的错误处理。如果你的错误处理总是相同的，那么是的，将其放入服务中。但是，如果您有多个功能模块或应用程序区域利用相同的服务，那么允许每个功能模块或应用程序区域独立处理其错误将为您提供最佳的模块化。与所有事情一样，这是一种权衡。当我跳转到客户的代码中时，如果我不必不断地从一个文件跳到另一个文件，我会更快乐。在维护过程中，能够跟踪管道并获得我所需的所有信息是一个巨大的生产力提升。