In pure Redux you would usually just create sibling success and error action types to be handled by the same reducer. Your components can then react to both of these cases based on what props are set from your state (usually either data or something set on error). How you handle side effects or async processes is another concern but in every case those "spin offs" should eventually dispatch the success data or error back into Redux.

What kind of errors? API call errors? form validation errors? unhandled javascript errors?

The answer depends on how you've set up your infrastructure. Are you using redux-thunk? redux-promise? redux-saga? something else?

I use redux-saga for async tasks like API calls... a typical saga might look something like this:

 function* fetchStuff() {
     while (true) {
         // this waits for the app to fire the FETCH_REQUEST action
         const { payload: id } = yield take(FETCH_REQUEST);
         try {
             // this makes the actual API call
             const stuff = yield call(fetch, `/api/stuff/${id}`);
             // this dispatches a new FETCH_SUCCESS action
             yield put(fetchSuccess(stuff));
         }
         catch (err) {
             // this dispatches a new FETCH_FAILURE action
             yield put(fetchFailure(err))
         }
     }
 }

So when the API call fails, an action called fetchFailure takes the err and it gets dispatched to the store. Then you would have a reducer (or middleware, or another saga) that watches for errors and does something appropriate -- e.g. show an error message inline on the page... pop up a dismissable message, etc.

Does that give you enough to go on? Or do you still need help?

If you're talking about breaking errors then as of react 16, error boundaries seems to be a nice way to handle errors and show users alternative views.