Redux: handling exceptions in reducers

[rewieer]

I believe we cannot throw any exception in reducers because it would return an empty object as a consequence. But what if I really need to handle exceptions inside my reducers to test error handling in my unit tests ?

Maybe reducers arn't the right place to throw errors and tests shouldn't make falsy operations on them ? Should the action creator be responsible of it ?

[sompylasar]

I believe we cannot throw any exception in reducers because it would return an empty object as a consequence.

It would not return anything as throw or a JavaScript error thrown from the JS engine like TypeError will interrupt the execution, and the exception will propagate up the call stack through redux internals back to where dispatch was called and further until the nearest try block. It may even break React if you dispatch from a component lifecycle hook (React will get into an inconsistent internal state because it does not handle exceptions thrown from the userland code).

[rewieer]

My mistake, it would indeed return nothing. Thanks for noticing.
Well, that mean using exceptions inside react lifecycle hook is already a bad idea. How to get around it ?

[sompylasar]

As we're in JavaScript which is mostly asynchronous by nature, I would suggest to keep away from exceptions which are a way of synchronous error handling.

Error handling is a part of business logic of an app, so it's better to put it where the business logic will reside.

There is an article about that in Redux FAQ: http://redux.js.org/docs/FAQ.html#structure-business-logic

There is a good overview of the options where business logic may reside in a redux app, their pros and cons: https://medium.com/@jeffbski/where-do-i-put-my-business-logic-in-a-react-redux-application-9253ef91ce1#.y09fsp98t It's biased towards its author's redux-logic module but gives good food for thought.

[timdorr]

A throw can essentially be thought of as a side effect, meaning your reducer functions are no longer pure. I would keep them to only managing incoming data and serializing that into a state tree, in as simple a manner as possible. Essentially, they are only reorganizing data that more complex code has already produced.

[andreyluiz]

Maybe reducers arn't the right place to throw errors and tests shouldn't make falsy operations on them ?

Reducers MUST BE pure! So, definitely is not the best place to handle this type of behavior. For my case I have a middleware that intercepts actions and check if the action has a property called message (or another name). Then it handles it throwing floating messages in my UI.

Another thing I see not much sense it to store the error messages in the redux's state. This, obviously is my case and my business logic, but, error are only relevant to quick show what happened in a floating message.