【问题标题】:rxjs error subscription not being triggered未触发 rxjs 错误订阅
【发布时间】:2020-08-20 08:52:49
【问题描述】:

我有一个 .net Core web-api 应用程序。 我故意从控制器返回一个异常,但我没有看到在订阅的错误处理中处理该异常。 这是我的代码(手工复制,因此可能会出现拼写错误): 控制器:

public IActionResult getSomeErrorAsTest()
{
    try
    {
        throw new Exception("Serer error");
    }
    catch(Exception ex)
    {
        return StatusCode(StatusCodes.Status500InternalServerError, new List<string>());
        //throw ex;
    }
}

角度服务:

export class MyService
{
    MyDataSubject = new Subject<any[]>();
    MyDataChanged :Observable>any[]> = this.MyDataSubject.asObservable();
    
    subscribe :Subscription;
    constructor(private httpClient : HttpClient)
    {
        this.subscribe = timer(0, 30000).pipe(
        switchMap(()=>
            this.getData())).subscribe();
    }
    getData()
    {
        return this.httpClient.get<any[]>(<controller url>)
        .pipe(
            tap(res =>
            {
                this.MyDataSubject.next(res);
            }),
            catchError(error =>
                {
                    debugger;//I would expect to catch the debugger here, but nothing happens
                    return throwError(error);
                })
            )
    }
}   

组件:

export class MyComponent (private mySrv : MyService)
{
    getMyData()
    {
        let sub =this.mySrv.MyDataChanged.subscribe(result => doSomething(),
                                                    error=> popUpAlert());
    }
}

【问题讨论】:

  • 你是说catchError 永远不会被执行吗?我可以看到为什么订阅中的错误回调永远不会执行,但catchError 仍然应该执行一次。
  • @fridoo - 不,catchError 永远不会执行。我可以在我的控制台(开发人员工具)中看到错误 500 消息和“您在预期流的位置提供了一个无效对象......”错误消息。你怎么能看到订阅中的错误回调从来没有被执行过——是不是写的方式有问题?
  • 在您的组件中订阅this.mySrv.MyDataChanged。这个 observable 永远不会出错,因为您只将值推入其中 (this.MyDataSubject.next(res))。如果您在某个时候调用this.MyDataSubject.error(..),则会出错。但我不确定你是否想在这个流上抛出错误。如果一个可观察的错误它终止并且之后不能发出任何其他东西。似乎您希望 observable 永远不会终止,因为您使用无限计时器作为触发器。

标签: angular rxjs asp.net-core-webapi angular-errorhandler


【解决方案1】:

正如@fridoo 指出的那样,您的组件正在订阅一个永远不会发出任何错误的可观察流。这是因为你有两个独立的 observables。

您实际上不需要维护主题并手动发出。您可以直接从getData 方法实现轮询和公开可观察的更改。

您甚至可以考虑将getData() 设为私有,只允许消费者使用MyDataChanged 可观察对象。 (也许重命名为 data$

export class MyService {
    data$: Observable<any[]> = timer(0, 30000).pipe(
        switchMapTo(this.getData()),
        distinctUntilChanged(compareFn)
    );
    
    constructor(private httpClient: HttpClient) { }

    private getData() {
        return this.httpClient.get(<controller url>).pipe(
            retry(2)
        );
    }

    compareFn(oldVal: any[], newVal: any[]) {
        // add logic to determine if emission
        // is considered to be different.
    }
}   

请注意,您不必订阅您的服务。你也不需要有一个单独的主题。这还有一个懒惰的好处,因为在实际订阅了 data$ observable 之前,http 调用不会开始轮询。

您可以选择在 getData() 方法或组件中捕获错误。

使用的运算符:

  1. switchMapTo - 由于您没有使用从计时器传递的参数,因此您可以使用这种更简洁的方法来代替常规的switchMap

  2. distinctUntilChanged - 将过滤掉相同的连续排放。您提供一个“比较函数”来确定一个值是否被认为与以前的不同。

  3. retry - 如果发生错误,可以方便地重试 http 调用。

现在,在您的组件中:

export class MyComponent {

    constructor(private mySrv: MyService){ }

    getMyData() {
        const sub = this.mySrv.data$.subscribe(
            result => doSomething(),
            error => popUpAlert()
        );
    }
}

如果我没有提到在模板中利用 async 管道而不是在控制器中管理订阅通常更简单,那我就失职了。

这种情况看起来像:

export class MyComponent {

    constructor(private mySrv: MyService){ }

    data$ = this.mySrv.data$.pipe(
        // tap(data => doSomething(data)), <-- hopefully you don't even need this
        catchError(error => { 
            popUpAlert(error);
        })
    );
}

然后是模板:

<ul>
    <li *ngFor="let item of data$ | async> {{ item.property }}</li>
</ul>

【讨论】:

  • 感谢您提供全面而详细的回答 - 我非常感谢您的努力。我会试试看。 distinctUntilChanged 函数是发生错误时发出的函数吗?
  • distinctUntilChanged 与错误无关。它只会防止发出重复数据。因此,当您进行 http 调用时,它会连续两次返回相同的结果,如果自上次发出后数据没有更改,data$ 将不会发出。您仍然可以在服务或组件中使用 catchError() 运算符。
  • 关于 distinctUntilChanged - 我已经在使用这个逻辑 - 发射不同的数据。我在你写的和我写的关于 catchError 的内容之间找不到任何真正的区别。我会尝试模仿你的解决方案,但真正的区别在哪里?
  • 不同之处在于您使用的是两个不同的数据流。您的组件正在订阅MyDataChanged。但是,您的错误将通过service.getData() 发出。因此,MyDataChanged 的使用者将永远无法捕获错误,因为错误永远不会通过该流发出。
  • 经过大量测试和阅读后,我发现最初的问题是 HTTP_INTERCEPTORS 的存在,它可能会“钓鱼”错误响应,并避免冒泡到客户端。除了这个,一切看起来都还不错。我希望这也能给大家带来一些价值。感谢您的努力。
猜你喜欢
  • 1970-01-01
  • 2016-08-06
  • 2023-03-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2021-12-22
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多