Melhores Práticas de Error Boundaries

Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção.

Conheça as duas camadas: try/catch para trabalho assíncrono e manipuladores de eventos; error boundaries para lançamentos de renderização e ciclo de vida - nenhum substitui o outro.
Envolva telas principais, não apenas a raiz: Um crash em uma folha não deve deixar o aplicativo inteiro em tela branca - boundaries por rota contêm o raio de explosão.
Mantenha um boundary raiz como último recurso: Captura falhas de provedores e bugs do shell de navegação - ainda registre e ofereça reinício, não uma tela em branco.
Use boundaries de classe ou react-error-boundary: Componentes funcionais não podem implementar getDerivedStateFromError - não finja boundaries com hooks.
Registre sempre em componentDidCatch: Crashes de produção sem telemetria são invisíveis - encaminhe para Sentry ou seu reporter antes de chamar reset.
Nunca mostre traces de pilha para usuários: A UI de fallback recebe cópia acionável; engenheiros leem logs - error.message vaza detalhes de implementação.
Redefina com remount ou refetch: reset() sozinho re-renderiza o mesmo estado corrompido - aumente uma key nos filhos ou refetch as queries da tela em onReset.
Tente/capture dentro de onPress: Lançamentos de manipuladores ignoram boundaries - envolva chamadas de módulo nativo e fetch e exiba toasts ou erros inline.
Diferencie erros offline de erros de servidor: NetInfo false não significa HTTP 500 - cópias e estratégias de retentativa diferentes para cada um.
Oculte o banner offline durante a sondagem de alcance: isInternetReachable === null no lançamento não significa offline - mostre o banner apenas em desconexão confirmada.
Conecte onlineManager ao NetInfo: TanStack Query deve pausar retentativas offline - retentativas ilimitadas em modo avião drenam a bateria.
Rotule dados em cache obsoletos: Mostre dataUpdatedAt ou "Dados salvos de …" durante SWR - os usuários precisam saber que preços ou saldos podem estar desatualizados.
Persista mutações falhas: UI otimista sem uma fila perde criações offline - AsyncStorage ou MMKV reproduzem com chaves de idempotência na reconexão.
Instale o manipulador global uma vez no bootstrap: ErrorUtils.setGlobalHandler no _layout raiz antes que as rotas sejam montadas - encadeie ao manipulador anterior após o registro.
Trate isFatal seriamente: Erros JS não tratados podem deixar o bundle em estado instável - relate imediatamente; não apenas console.warn.
Capture rejeições de promessa não tratadas: Adicione onunhandledrejection (onde suportado) como uma rede de segurança ao lado de setGlobalHandler.
Não recarregue o aplicativo em Retry: Updates.reloadAsync() descarta o estado na memória - prefira refetch() ou reset do boundary.
Recursos de flag para telas arriscadas: Kill switch remoto mais contador de crash local desabilita automaticamente uma tela após viagens repetidas do boundary.
Cacheie payloads de flag com TTL: Padrões do AsyncStorage permitem que o aplicativo inicie quando o serviço de flag está inativo - stale-off é mais seguro que stale-on para novos crashes.
Modele níveis de capacidade: full / degraded / unavailable para biometria, localização e câmera - degrade com cópia clara, não lance exceções.
Use requireOptionalNativeModule em caminhos do Expo Go: Classes nativas ausentes devem degradar recursos - não travar no momento da importação.
Mapeie erros para categorias visíveis ao usuário: Rede, autenticação, validação e desconhecido recebem cada um um título + ação distintos - um genérico "Algo deu errado" é um último recurso.
Ofereça uma ação de recuperação primária: Tentar novamente, Voltar ou Contatar suporte - não três botões iguais que paralisam usuários de celular.
Mantenha o JSX de fallback do boundary trivial: Sem busca de dados dentro do componente boundary - lançamentos no fallback escalam para o boundary pai.
Teste o modo avião e o reset do boundary no dispositivo: Simuladores escondem o flapping do NetInfo e as corridas de remount - scripts de QA devem incluir caminhos de offline + retentativa + kill-switch.

FAQs

Error boundaries capturam erros de async await?

Não - a menos que a rejeição ocorra durante a renderização (anti-padrão).
Use try/catch na função assíncrona ou deixe o TanStack Query exibir isError.

Quantos boundaries um aplicativo de abas precisa?

Um por tela de pilha primária mais um boundary raiz.
Abas de recursos pesados (checkout, mapas) merecem seus próprios, mesmo quando aninhados.

Handlers globais devem substituir o Sentry?

Não - encaminhe para o Sentry (ou similar) tanto do manipulador global quanto do componentDidCatch.
O manipulador global captura o que os boundaries perdem; os boundaries adicionam contexto de tela.

Quando feature flags superam hotfix OTA?

Quando uma tela específica trava no lançamento e você precisa de um switch instantâneo sem esperar pela revisão da loja.
Combine com um hotfix OTA ou build de loja - flags contêm danos; elas não substituem o patch.

Relacionados

Noções Básicas de Tratamento de Erros - tour try/catch vs boundaries
Error Boundaries em RN - fallbacks de tela e UI de recuperação
UX de Falha de Rede - banners offline e filas de retentativa
Manipuladores Globais de Erro - ErrorUtils e rejeições não tratadas
Feature Flags para Rollout Seguro - kill switches
Cópia de Erro Voltada ao Usuário - mensagens acionáveis

Versões de Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0, e Expo SDK 57 (expo ~57.0.4).

Melhores Práticas de Error Boundaries

Um resumo condensado das 25 melhores práticas mais importantes extraídas de todas as páginas desta seção.

Conheça as duas camadas: try/catch para trabalho assíncrono e manipuladores de eventos; error boundaries para lançamentos de renderização e ciclo de vida - nenhum substitui o outro.
Envolva telas principais, não apenas a raiz: Um crash em uma folha não deve deixar o aplicativo inteiro em tela branca - boundaries por rota contêm o raio de explosão.
Mantenha um boundary raiz como último recurso: Captura falhas de provedores e bugs do shell de navegação - ainda registre e ofereça reinício, não uma tela em branco.
Use boundaries de classe ou react-error-boundary: Componentes funcionais não podem implementar getDerivedStateFromError - não finja boundaries com hooks.
Registre sempre em componentDidCatch: Crashes de produção sem telemetria são invisíveis - encaminhe para Sentry ou seu reporter antes de chamar reset.
Nunca mostre traces de pilha para usuários: A UI de fallback recebe cópia acionável; engenheiros leem logs - error.message vaza detalhes de implementação.
Redefina com remount ou refetch: reset() sozinho re-renderiza o mesmo estado corrompido - aumente uma key nos filhos ou refetch as queries da tela em onReset.
Tente/capture dentro de onPress: Lançamentos de manipuladores ignoram boundaries - envolva chamadas de módulo nativo e fetch e exiba toasts ou erros inline.
Diferencie erros offline de erros de servidor: NetInfo false não significa HTTP 500 - cópias e estratégias de retentativa diferentes para cada um.
Oculte o banner offline durante a sondagem de alcance: isInternetReachable === null no lançamento não significa offline - mostre o banner apenas em desconexão confirmada.
Conecte onlineManager ao NetInfo: TanStack Query deve pausar retentativas offline - retentativas ilimitadas em modo avião drenam a bateria.
Rotule dados em cache obsoletos: Mostre dataUpdatedAt ou "Dados salvos de …" durante SWR - os usuários precisam saber que preços ou saldos podem estar desatualizados.
Persista mutações falhas: UI otimista sem uma fila perde criações offline - AsyncStorage ou MMKV reproduzem com chaves de idempotência na reconexão.
Instale o manipulador global uma vez no bootstrap: ErrorUtils.setGlobalHandler no _layout raiz antes que as rotas sejam montadas - encadeie ao manipulador anterior após o registro.
Trate isFatal seriamente: Erros JS não tratados podem deixar o bundle em estado instável - relate imediatamente; não apenas console.warn.
Capture rejeições de promessa não tratadas: Adicione onunhandledrejection (onde suportado) como uma rede de segurança ao lado de setGlobalHandler.
Não recarregue o aplicativo em Retry: Updates.reloadAsync() descarta o estado na memória - prefira refetch() ou reset do boundary.
Recursos de flag para telas arriscadas: Kill switch remoto mais contador de crash local desabilita automaticamente uma tela após viagens repetidas do boundary.
Cacheie payloads de flag com TTL: Padrões do AsyncStorage permitem que o aplicativo inicie quando o serviço de flag está inativo - stale-off é mais seguro que stale-on para novos crashes.
Modele níveis de capacidade: full / degraded / unavailable para biometria, localização e câmera - degrade com cópia clara, não lance exceções.
Use requireOptionalNativeModule em caminhos do Expo Go: Classes nativas ausentes devem degradar recursos - não travar no momento da importação.
Mapeie erros para categorias visíveis ao usuário: Rede, autenticação, validação e desconhecido recebem cada um um título + ação distintos - um genérico "Algo deu errado" é um último recurso.
Ofereça uma ação de recuperação primária: Tentar novamente, Voltar ou Contatar suporte - não três botões iguais que paralisam usuários de celular.
Mantenha o JSX de fallback do boundary trivial: Sem busca de dados dentro do componente boundary - lançamentos no fallback escalam para o boundary pai.
Teste o modo avião e o reset do boundary no dispositivo: Simuladores escondem o flapping do NetInfo e as corridas de remount - scripts de QA devem incluir caminhos de offline + retentativa + kill-switch.

FAQs

Error boundaries capturam erros de async await?

Não - a menos que a rejeição ocorra durante a renderização (anti-padrão).
Use try/catch na função assíncrona ou deixe o TanStack Query exibir isError.

Quantos boundaries um aplicativo de abas precisa?

Um por tela de pilha primária mais um boundary raiz.
Abas de recursos pesados (checkout, mapas) merecem seus próprios, mesmo quando aninhados.

Handlers globais devem substituir o Sentry?

Não - encaminhe para o Sentry (ou similar) tanto do manipulador global quanto do componentDidCatch.
O manipulador global captura o que os boundaries perdem; os boundaries adicionam contexto de tela.

Quando feature flags superam hotfix OTA?

Quando uma tela específica trava no lançamento e você precisa de um switch instantâneo sem esperar pela revisão da loja.
Combine com um hotfix OTA ou build de loja - flags contêm danos; elas não substituem o patch.

Relacionados

Noções Básicas de Tratamento de Erros - tour try/catch vs boundaries
Error Boundaries em RN - fallbacks de tela e UI de recuperação
UX de Falha de Rede - banners offline e filas de retentativa
Manipuladores Globais de Erro - ErrorUtils e rejeições não tratadas
Feature Flags para Rollout Seguro - kill switches
Cópia de Erro Voltada ao Usuário - mensagens acionáveis

Versões de Stack: Esta página foi escrita para React 19.2.3, React Native 0.86.0, e Expo SDK 57 (expo ~57.0.4).

Melhores Práticas de Error Boundaries

FAQs

Relacionados

Buscar na documentação

Melhores Práticas de Error Boundaries

FAQs

Relacionados