O que há de errado com o uso de Thread.Abort ()

Então eu sei que você não deveria usar

Thread.Abort() 

Mas nunca recebi uma boa explicação. Existe uma penalidade de desempenho ou alguma pegadinha escondida?

Eu sei que você não pode ignorar / engolir o ThreadAbortException (o que faz sentido)

Além de todas as outras boas respostas aqui, deixe-me acrescentar que não há nenhuma garantia de que uma chamada para Thread.Abort realmente abortará o thread em questão, nunca. É possível (embora não particularmente fácil) “endurecer” um encadeamento contra o aborto. Se, por exemplo, você está abortando um thread porque acredita que ele está executando código hostil, então o código hostil pode estar resistindo à sua própria destruição.

Se você tiver uma operação demorada envolvendo código que não possui e que deve ser removido corretamente, a maneira correta de fazer isso é colocar esse código em seu próprio processo , não em seu próprio encadeamento. (E, de preferência, em um appdomain altamente restrito à segurança nesse processo.) Você pode, então, eliminar o processo.

Em suma, Thread.Abort é, na melhor das hipóteses, indicativo de design ruim, possivelmente não confiável e extremamente perigoso. Deve ser evitado a todo custo; a única vez que você deve considerar abortar um tópico está em algum tipo de código de “desligamento de emergência”, no qual você está tentando derrubar um appdomain da forma mais limpa possível.

Porque se você sabe que o thread está em algum estado seguro no qual ele pode ser abortado, certamente você pode organizar uma melhor comunicação e fazer com que a saída do thread seja limpa.

O thread poderia ter tido um bloqueio e estar no meio de alterar algum estado compartilhado, e o Thread.Abort desfará o bloqueio e deixará o estado compartilhado corrompido.

É mais fácil se machucar. Como outros afirmaram, ele gera uma exceção no código, que pode ocorrer a qualquer momento. Isso pode ser bom se você espera isso e tiver codificado de uma maneira que manipule elegantemente essa exceção a qualquer momento, mas algumas pessoas não:

 Monitor.Enter(obj); // some code - if exception is raised here, then the lock isn't released Monitor.Exit(obj) IDisposable someCriticalResource = GetResource(); // some code - if exception is raised here, then the object isn't disposed someCriticalResource.Dispose(); 

Além disso, se você estiver trabalhando com muitas pessoas em uma equipe, a menos que tenha boas avaliações de código, não poderá garantir a qualidade do código com o qual estará trabalhando. Por isso, é uma boa ideia pregar o gospal de “no Thread.Abort ()” do que fazer com que as pessoas lembrem-se de escrever um código que seja robusto contra exceções que ocorram em qualquer lugar dentro desse código.

Em resumo. Qualquer object IDisposable não pode ser descartado. Qualquer object bloqueado não pode ser desbloqueado. Tudo o que deve ser 100% realizado nunca será feito.

Quando você chamar Thread.Abort () em outro thread um ThreadAbortException é injetado no stream desse segmento. Se você tiver sorte, o código tratará bem e abortará em um estado bem definido. O problema é que você não tem como descobrir se você terá sorte em todos os casos, então se você preferir evitar erros ao chamar Thread.Abort em outros tópicos não é uma boa idéia.

Thread.Abort pára o seu segmento de uma forma descontrolada. thread.Abort lançará uma exceção, o que fará com que o seu segmento pare imediatamente.

O que há de errado com isso: na maioria dos casos, você deseja interromper a operação que está realizando normalmente. Por exemplo, se você estiver executando uma operação ACID, talvez queira concluir a operação atual antes de finalizar o encadeamento, para que seu sistema permaneça em um estado estável.

Thread.Abort aumenta uma exceção no segmento de destino. O thread de destino pode estar realizando algumas operações críticas e o aumento de uma exceção pode quebrar o estado do seu aplicativo.