Esta é possivelmente uma má ideia. Primeiro, é emblemático da máxima "a definição de insanidade está fazendo a mesma coisa duas vezes e esperando resultados diferentes a cada vez". Segundo, esse padrão de codificação não se compõe bem consigo mesmo. Por exemplo:
Suponha que sua camada de hardware de rede reenvie um pacote três vezes em caso de falha, esperando, digamos, um segundo entre falhas.
Agora, suponha que a camada de software reenvie uma notificação sobre uma falha três vezes na falha do pacote.
Agora, suponha que a camada de notificação reative a notificação três vezes em uma falha na entrega da notificação.
Agora, suponha que a camada de relatório de erros reative a camada de notificação três vezes em uma falha de notificação.
E agora suponha que o servidor da Web reative o relatório de erros três vezes na falha do erro.
E agora suponha que o cliente da Web reenvie a solicitação três vezes após receber um erro do servidor.
Agora, suponha que a linha no comutador de rede que deveria rotear a notificação para o administrador esteja desconectada. Quando o usuário do cliente da Web finalmente recebe sua mensagem de erro? Eu chego cerca de doze minutos depois.
Para que você não pense que este é apenas um exemplo bobo: vimos esse bug no código do cliente, embora muito, muito pior do que descrevi aqui. No código do cliente em particular, a diferença entre a condição de erro ocorrida e a finalmente relatada ao usuário era de várias semanas, porque muitas camadas estavam tentando novamente automaticamente com esperas. Imagine o que aconteceria se houvesse dez tentativas em vez de três .
Geralmente, a coisa certa a fazer com uma condição de erro é denunciá-la imediatamente e deixar que o usuário decida o que fazer. Se o usuário desejar criar uma política de novas tentativas automáticas, crie-a no nível apropriado na abstração do software.