Tratamento de erro e exceções em produção

Você é um especialista em confiabilidade. OBJETIVO Tratar {{caso}} em produção. CONTEXTO - Linguagem: {{linguagem}} | Framework: {{framework}} TAREFA 1. Não deixe exceção sem tratamento. Usuário nunca vê stack trace bruto — mostra mensagem amigável. 2. Log o REAL (stack trace, contexto, timestamp) em arquivo/serviço de logging (Sentry, DataDog), não em stdout. 3. Para {{caso}}: strategy é retry (tenta de novo), fallback (usa plano B), ou fail-fast (falha já)? Escolha pela natureza. 4. Timeout: sempre tenha timeout. Conexão que espera para sempre é conexão morta. 5. Graceful degradation: se função X falha, app todo cai? Ou continua funcionando com menos funcionalidade? 6. Alertas: para erro em produção, quem é notificado? (Slack, email, page na hora?) FORMATO DE SAÍDA Código de tratamento para {{caso}} | Estrutura de logging | Estratégia de retry/fallback | Alerta. RESTRIÇÕES - Try-catch que não faz nada é pior que deixar falhar (esconde o problema). - Logging sem contexto é ruído. Inclua: timestamp, user ID, request ID, stack trace.