相关文章推荐
重感情的墨镜  ·  android推送系统通知 ...·  1 年前    · 
高兴的眼镜  ·  Self-signed ...·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

The question I have is for something I've been scratching my head about recently --

In my interceptor, I have code that parses and handles certain errors, and will act in certain ways depending on an error's status code, etc (I didn't include this code due to it not really serving any purpose to this question, but if someone has a good reason as to why I should include it, I absolutely can.

I am trying to figure out how to handle net :: ERR_TIMED_OUT (Using google chrome / opera) in my interceptor. I've tracked it down to a point where I can tell that a request IS being built and being 'handled', but after that, the request and response are both gone. My initial thought here is that there is an XMLHttpRequest error somewhere and it is being suppressed in some way and the response is being thrown out.

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const intercepted = this.setHeaders(req);
    return this.SetPendingRequests(next.handle(intercepted))
            .pipe(catchError((err): Observable<HttpEvent<any>> => {
                return this.ParseErrorResponse(err);

I've tried adding finalize(() => {}) to it as well and that works fine in every case except for this one, where ERR_TIMED_OUT just basically seems to decide that all things must stop for it.

I've also tried hooking into XMLHttpRequest directly and angular didn't take that too kindly - as I feel the root of the problem could stem from that itself.

All google/stackoverflow searches pretty much point to it being a local issue, but I feel as if there should be some way to handle it in my code so if a user were to run into this error while using my app, I'd be able to handle that appropriately. Basically, I just want any request for ERR_TIMED_OUT (which oddly enough, other browser base errors return an error of 'Unknown Error' type -- this is the only odd outlier I've found that just simply stops everything. I'm looking to see if anyone else has run into this issue / would be willing to help aid me in sniffing it out.

Appreciate any help on the matter and thanks in advance,

A quick update to my issue -- I seem to have found a solution inside of RxJS. Turns out RxJS has though of everything and indeed, this has seemed to fix the issue I had (among building out other things to react on certain errors, etc)

The interceptor code i built out looks something like this.. (I chose 20000 as the default for Chrome in my instance was 30 seconds for a browser timeout...)

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
    const intercepted = this.setHeaders(req);
    return this.SetPendingRequests(next.handle(intercepted))
            .pipe(timeout(20000),
            catchError((err): Observable<HttpEvent<any>> => {
                return this.ParseErrorResponse(err);

The timeout operator should return a usable error rather than shooting 1's and 0's off into space with no guarantee that they'd ever return in the case of an actual timeout. This also overrides any browser based timeout (If my network call times out in 20 seconds from the RxJS operator, it will not then timeout again in the browser. The error is thrown and life goes on). Being able to be reactive to errors is a great thing too I've found with error handling, so that makes it all the better.

It's also worth noting that this works on network calls - which is primarily where I'm using it at the moment.

As always, I'm open to better / more elegant solutions -- I am an engineer and forever a student after all, but hopefully this helps someone that was having a similar issue to me.

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question. Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.