Redux: Errors are getting lost in the shuffle

[volkanunsal]

The error messages from a specific function in my app are getting swallowed up somewhere in React or Redux. I haven't pinned down exactly where this is happening, but my hunch tells me that this try/finally block may be the root cause.

    try {
      isDispatching = true;
      currentState = currentReducer(currentState, action);
    } finally {
      isDispatching = false;
    }

The error behavior is very peculiar and it is hard to describe, let alone reproduce. The first time the function is called, the errors work fine. However, if the function is called a second time, for example from a componentDidUpdate block, the error are not thrown at all. I had to wrap the body of the function just to make sure there was error being thrown inside it.

This bug is hard to replicate, and I hope I managed to communicate the gist of it. I will keep investigating tomorrow.

[gaearon]

Please keep investigating! Redux never catches exceptions. Try/finally block does not catch anything.

[gaearon]

Don't forget you can check "Break on All Exceptions" in Chrome DevTools to see if your error is swallowed by some code.

[gaearon]

I'm closing because we have no catch-es in the codebase, please reopen if you can reproduce.

Do you use Redux DevTools? It catches reducer exceptions (and shows them), but it still logs them to console.

[tpreusse]

I had a similar problem but the cause was not redux.

However running dispatch within the then callback of a promise is dangerous. Specifically because exceptions in a then callback of a already resolved promise are ignored. Now since redux runs synchronously that means any render exception will be ignored when the render happens because of a dispatch in a then block of a already resolved promise.

To demonstrate I've adapted @gaearon Redux MircoBoilerplate:
https://gist.github.com/tpreusse/3d007762ed1026aefe47#file-reduxmicroboilerplate-js-L54

Unfortunately there is at least one ajax library that does return a resolved promise. So if you take the original gist and simply do import { get as fetch } from 'axios'; you have exactly this issue. And thats why I'm here after 2 hours of debugging ;-(

Maybe this is something to mention in the docs? Or always include a catch block in the docs? I do feel like rendering from within a then block is a anti pattern but dispatch being synchronous is the greatest thing ever...

[volkanunsal]

because exceptions in a then callback of a already resolved promise are ignored. Now since redux runs synchronously that means any render exception will be ignored when the render happens because of a dispatch in a then block of a already resolved promise.

This is what happened with me, too. On the fetch issues page, I got a pretty thorough answer with the suggestion of adding adding the error callback as the second argument to a then clause in order to prevent this type of error. I haven't tried it yet, but I will report back how it goes.

[tpreusse]

At least GH fetch seems to be doing it right and does not return a resolved promise – did you attach a catch handler yourself which did not rethrow the exception?

I opened a issue at axios to get it resolved there:
https://github.com/mzabriskie/axios/issues/103

Would still be nice to add a warning to the redux async docs to be careful with then handlers.

[volkanunsal]

did you attach a catch handler yourself which did not rethrow the exception?

Yeah, I attached a catch at the end of the chain, but I had no idea about this global catch-all behavior. The documentation doesn't explain it clearly.

[gaearon]

Yeah, I attached a catch at the end of the chain, but I had no idea about this global catch-all behavior. >The documentation doesn't explain it clearly.

Which documentation are you referring to? Redux docs assume you know about Promise error catching behavior and its pitfalls.

[volkanunsal]

@gaearon Whoops, I meant the fetch docs.