StatsHub Docs

Errors

One reporting sink, boundaries layered by how much they tear down, and the four rules that keep failures visible.

One sink

Everything that fails goes through a single reporting function. Nothing calls console.error to report a problem.

The reason is that this gives you one place to add Sentry, or a debug overlay, or a rate limiter, instead of an audit of every log statement in the codebase. Adding a destination is one call in one file.

Boundaries are layered

The only question a boundary answers is "how much do I tear down". So there is one at each scale where a different answer is right.

At the root, above the providers, sits the outermost boundary. Its fallback is drawn with React Native primitives only, no design system — it has to be able to render when the design system provider is the thing that broke.

At the screen level there is one boundary per route. A crash in one board leaves the navigation stack, the tab bar and every other screen alive.

At the row level, applied once inside the shared list layout, a boundary means one bad entry in a response of thirty says so in place while the other twenty-nine still scroll. This is the highest-value one in the app, because a row renders the API's data at its rawest.

At the section level there is a boundary for anything independently useless, like a chart or a panel that has nothing to do with the rest of the screen.

What boundaries cannot catch

React boundaries only see errors thrown during render. They do not see a throw inside an onPress, a timer, or an unawaited promise. Those are covered by global handlers installed at startup and by a small set of wrappers.

The four rules

These are short because they need to be remembered, not looked up.

  1. Nothing calls console.error to report a failure. Report it properly.
  2. No promise is left without a handler. Await it or fire it deliberately.
  3. No event handler that can throw is passed bare. Wrap it.
  4. No parsed JSON is trusted without a shape check. This includes anything read back off disk, which is the one people forget.

Rule four is the one that actually bites. Stored data was written by an older version of the app, and the shape you are reading is whatever that version happened to write.

On this page