与RXJS catchError一起使用时，预期抛出实际上会崩溃

Question

it('minimal test case', () => {
    expect(() => {
        of(1).pipe(
            map(() => {
                throw new Error('err');
            }),
            catchError(() => {
                throw new Error('new err');
            }),
        ).subscribe();
    }).toThrow();
});

这段代码实际上会崩溃Jasmine/Karma的整个执行，即使在原始的错误堆栈跟踪中也会导致错误内部的捕获错误。

我认为如果可观察抛出并且无法处理它应该在它所在的上下文中传播该错误。否则，我无法测试可观察是否抛出。

此（茉莉花）测试将产生以下错误：

未捕获错误：CatchSubscriber.selector （slideshow.directive.spec.ts：224） 上的新错误 catchSubscriber.push.../../node_modules/rxjs/_esm5/internal/operators/catchError.js.CatchSubscriber.error （catchError.js：34） at MapSubscriber.push.../../node_modules/rxjs/_esm5/internal/operators/map.js.MapSubscriber._next （map.js：38） at MapSubscriber.push.../../node_modules/rxjs/_esm5/internal/Subscriber.js.Subscriber.next （Subscriber.js：53） at Observable._subscribe （subscribeToArray.js：5） at Observable.push.../../node_modules/rxjs/_esm5/internal/Observable.js.Observable._trySubscribe （Observable.js：43） at Observable.push.../../node_modules/rxjs/_esm5/internal/Observable.js.Observable.subscribe （Observable.js：29） at MapOperator.push.../../node_modules/rxjs/_esm5/internal/operators/map.js.MapOperator.call （map.js：18） at Observable.push.../../node_modules/rxjs/_esm5/internal/Observable.js.Observable.subscribe （Observable.js：24） at CatchOperator.push.../../node_modules/rxjs/_esm5/internal/operators/catchError.js.CatchOperator.call （catchError.js：18）

TypeError:无法读取ContextKarma的directCallParentKarmaMethod（context.js:270）中未定义的属性“error”。handleGlobalErrors的错误（context.js:155）和KarmaReporter的错误（adapter.js:176）。suiteDone（adapter.js:224）在dispatch（jasmine.js:4560）在ReportDispatcher。suiteDone（jasmine.js:4531）位于nodeComplete（jasmine.js:1019）和onComplete处（JasmineJS:5528）位于ZoneDelegate…/../node_modules/zone.js/dist/zone/js.ZoneDeligate。在zone…/../node_modules/zone.js/dist/zone/js.zone处调用任务（zone.js:423）。runTask（zone.js:195）

预期函数将引发异常。在用户上下文中。(http://localhost:9876/src/app/shared/thumbnail/slideshow.directive.spec.ts?:227:6)在ZoneDelegate…/../node_modules/zone.js/dist/zone/js.zoneDelegte。调用(http://localhost:9876/C:/Users/uzivatel/Documents/nubium/ulozto-web/angular/node_modules/zone.js/dist/zone。js？：391:1）在ProxyZoneSpec.push…/../node_modules/zone.js/dist/zone-testing.js.ProxyZoneSpec。奥尼沃克(http://localhost:9876/C:/Users/uzivatel/Documents/nubium/ulozto-web/angular/node_modules/zone.js/dist/zone-testing。js？：289:1）在ZoneDelegate…/../node_modules/zone.js/dist/zone/js.zoneDelegte。调用(http://localhost:9876/C:/Users/uzivatel/Documents/nubium/ulozto-web/angular/node_modules/zone.js/dist/zone/js？：390:1)

Answer 1

一种可能的解决方案是将错误重定向到成功路径，然后测试该值。当所测试的流具有连接到抛出不同错误类型的逻辑时，这可能很有用（尽管在这种情况下，对Error的测试当然是不够的）。

  it('should be of type error', () => {
    of(1)
      .pipe(
        map(() => {
          throw new Error('err');
        }),
        catchError(error => of(error)))
      .subscribe(result => {
        expect(result instanceof Error).toBe(true);
      });
  });

但是一种更常见的方法是测试是否调用了正确的回调，正如JB Nizet所提到的。例如，您的服务有一个handleError方法，当流出错时应该调用该方法。