O que fazer ao permitir que o aplicativo seja executado em um estado inválido?

Puxa isso soa familiar.

Eu já fui o gerente de um grupo que tinha um grande aplicativo que tinha algumas exceções não tratadas que acabaram sendo capturadas como um manipulador global de capturar tudo e exibir o mundo. Por padrão, isso é usado para permitir que o aplicativo continue em execução.

Seu ponto sobre o estado do aplicativo neste caso é o mesmo que eu fiz: o aplicativo não deve continuar em execução porque seu estado interno é desconhecido e provavelmente suspeito (afinal, uma exceção veio a ser levantada em primeiro lugar) ).

Eu queria que o aplicativo fosse modificado para que o usuário pudesse salvar os dados e, em seguida, o aplicativo fosse encerrado, sem a oportunidade de continuar. Isso foi enfrentado por uma resistência feroz, principalmente por parte de desenvolvedores que argumentaram que ela havia continuado por um longo tempo e que havia um dano mínimo - apenas muitas reclamações. No final, tive que recuar - o usuário tinha permissão para continuar, mas os diálogos eram alterados para sugerir aos usuários que eles deveriam sair e reiniciar. Eu ainda acho que isso estava errado.

No final, todas as exceções que são vistas precisam ser analisadas para encontrar a causa subjacente e as correções apropriadas, as alterações de código ou o que for necessário ser aplicado para que as exceções não ocorram - ou se elas forem capturadas como parte do fluxo normal do programa e manipulado localmente.

(Às vezes, infelizmente, as exceções são propagadas de coisas como bibliotecas. Uma das regras que me ensinaram há muito tempo atrás foi: "não confie em exceções para o fluxo normal do programa". Parece que isso não é sempre praticada regularmente mais.)

Sinto sua dor - mas, no final, o princípio é simples e você deve se ater a ele: Quando o manipulador de exceção de última chance é demitido, as coisas estão realmente doentias. O programa deve sair. Fazer o contrário dá aos usuários a impressão enganosa de que eles podem continuar trabalhando, mas internamente o programa tem um estado desconhecido ou quebrado. Continuar a trabalhar só leva a que as coisas piorem progressivamente. No final, isso se traduz em perda de satisfação do cliente. Os clientes também ficam irritados com um programa que gera uma exceção e sai - se houver um estado de programa não salvo, tente salvá-lo, talvez de uma maneira que deixe claro que o que é salvo pode não ser confiável. Pelo menos você reduz a chance de perda de dados. Mas continuando a operar ... má jogada ruim. Você tem que escolher o menor de 2 males.

Eu posso entender o ponto que seus gerentes de aplicativos estão tentando fazer, que simplesmente desligar ou reiniciar imediatamente ao encontrar um erro inesperado pode confundir um usuário. Você sempre quer dar ao usuário informações sobre o que aconteceu e, se possível, dar a eles uma escolha sobre como eles gostariam de lidar com isso.

Você também pode tentar localizar o problema em um componente específico que talvez possa ser recarregado ou sincronizado novamente, para evitar que outras áreas de trabalho do aplicativo precisem ser desativadas?

Por outro lado, se continuarem a trabalhar e possivelmente corrompendo dados persistentes que podem causar problemas futuros para si ou para outros, OU se esses dados corrompidos ou incorretos precisarem de intervenção manual para limpar de alguma forma, então você tem um caso para fechar o aplicativo o mais rápido possível. Apenas certifique-se que é informativo e gracioso (... tão gracioso como uma falha de aplicativo poderia ser:)

Talvez seus esforços estejam mais focados em estabilizar o aplicativo para onde exceções inesperadas ocorram muito menos e as exceções esperadas sejam muito maiores.

É definitivamente uma boa prática desligar o aplicativo que lançou uma exceção não tratada. Sob o Winforms no .NET, costumava haver um diálogo que aparecia e lhe dava um grande aviso com a opção de continuar rodando. Mas como acho que o .NET 3.5 que continua opção não está mais lá e você é forçado a desligar o aplicativo.

Se você, em seguida, reiniciar o aplicativo automaticamente é com você - eu vi isso feito por alguns outros softwares principais, como navegadores.

A caixa de diálogo do nosso manipulador de exceções catch 'global' exibe o rastreio da pilha e outras informações (nome da máquina, hora, mensagem de erro, nome de usuário atual, etc) em uma caixa de texto que pode ser copiada para a área de transferência. Um botão está disponível para o suporte por e-mail com as informações (o botão tem o nome 'Enviar relatório de erros'). Na minha experiência, o usuário provavelmente não se incomodará em informá-lo sobre isso, a menos que eles recebam um meio fácil como esse para enviar um e-mail para você. E gravar os detalhes da exceção em um arquivo de log, embora ainda seja necessário, não será muito útil para o desenvolvedor até que você tenha acesso ao arquivo ou à máquina.

Dependendo da situação, há uma resposta que usei uma vez: Se algo der errado, mas não houver uma fatalidade, eu redefinir o nome do documento - se o trabalho for corrompido, ele não substituirá o original. Pretendia-se apenas permitir-lhes tempo para uma saída elegante.