Tratamento de erros
Defina falhas, seus responsáveis e o que permanece seguro após uma falha. Isto é uma orientação, não uma lista de verificação.
Falhas tipadas e estruturadas
Falhas esperadas precisam de tipos declarados, discriminantes estáveis e detalhes relevantes para o tratamento. Reutilize as convenções de erro do projeto, preserve as causas e separe a identidade da máquina do texto de exibição. Nunca direcione o tratamento analisando mensagens. Defeitos inesperados, como uma falha na verificação de exaustividade, podem permanecer como erros simples; a contenção nunca deve transformá-los em sucesso.
Capturar, recuperar ou interromper
Para cada falha, defina os responsáveis pelo tratamento e relato, a contenção e as garantias na documentação da API proprietária: quais invariantes permanecem válidas, se os efeitos estão ausentes, parciais, confirmados ou desconhecidos, e quem é responsável pela limpeza. O trabalho em segundo plano mantém essas obrigações.
Capturar limita a propagação de exceções, não as mutações. Apenas o dono do estado afetado pode estabelecer uma continuação segura. Caso contrário, interrompa o trabalho dependente, descarte estado ou instâncias inválidas, ou escale. Apenas registrar não é recuperação. Retentativas exigem repetição segura, cancelamento e um responsável explícito; operações finitas precisam de orçamentos, enquanto a supervisão contínua precisa de propriedade do ciclo de vida e degradação observável.
Relatórios localizados, acionáveis e visíveis
Todo relatório final precisa de um resumo legível, a operação afetada e uma próxima ação segura. Localize através do mecanismo de localidade do aplicativo receptor, quando existir; outros diagnósticos usam seu idioma de saída existente. Mantenha detalhes internos confidenciais fora do texto voltado ao usuário.
Estado não confiável ou resultados desconhecidos devem ser visíveis através da interface do usuário ou logs acessíveis por padrão: relate o impacto, a incerteza, o que o sistema fez e o próximo passo seguro. Estado inválido persistente precisa de visibilidade persistente. Nunca declare sucesso, reversão ou retentativa segura sem as garantias por trás deles. Falhas no relatório precisam de um fallback independente.
Verifique o estado resultante e o resultado visível, não apenas que uma exceção foi capturada.
Fundamentos
Meyer, Object-Oriented Software Construction (1997): contratos e invariantes. Sutter, Exceptional C++ (1999): garantias de segurança de exceção. Armstrong, Making reliable distributed systems in the presence of software errors (2003): isolamento e supervisão.