Error Handling

Handling errors it something very important to do, especially in applications that have a lot of HTTP requests and have complicated state.

It allows for the application to handle various unanticipated behaviour in a way where the users are affected as minimally as possible.

In our Feeds SDK we differentiate between 3 types of errors:

• API Errors
• Hook errors
• Unhandled errors

API Errors

These are typically errors thrown from one of our APIs. They will always throw upstream in order to allow integrations to handle them as they see fit.

Hook Errors

These are errors that might occur from hooks within the SDK that do API requests (useCreateFeedsClient is one example of this). The hooks will also make sure to throw upstream, from within the render function; so that they can be caught within a React ErrorBoundary in integrations.

Unhandled Errors

These are errors that might occur within the SDK from deep within (for example if an API request is done when reacting to a WebSocket event) that can neither be thrown nor handled in a way where integrators are aware of them.

For this purpose, we’ve introduced a local event with the type of errors.unhandled.

The event will always contain an error_type property, which determines the type of unhandled error that has been dispatched.

Provided below are all of the currently available unhandled error types:

This event will always be fired on the client, meaning it can be listened to by doing client.on('errors.unhandled', (e) => { ... }).

Example

client.on("errors.unhandled", (event) => {
  const errorType = event.error_type;

  switch (errorType) {
    case UnhandledErrorType.ReconnectionReconciliation: {
      updateErrorStateStore(event.failures);
      break;
    }

    case UnhandledErrorType.SomeOtherUnhandledError: {
      displayErrorSnackbar(errorType);
      break;
    }

    default: {
      console.warn(`Unrecognized error ${errorType} has been dispatched.`);
    }
  }
});