Est-ce que .NET a une exception semblable à EAbort de Delphi?

Question

Est-ce que .NET a une exception semblable à EAbort de Delphi?

Actuellement, je définis ma propre exception "AbortProcess" héritant de l'exception. Ensemble avec le gestionnaire My.Application.UnhandledException qui ignore "AbortProcess" Je me demande toujours si un mécanisme similaire dans .NET existe déjà.

Class AbortProcess 
    Inherits System.Exception 
End Class 

Sub Abort() 
    Throw New AbortProcess() 
End Sub 

Sub AppDomain_UnhandledException(ByVal sender As Object, ByVal e As ApplicationServices.UnhandledExceptionEventArgs) 
    If TypeOf e.Exception Is AbortProcess Then 
     e.ExitApplication = False 
    End If 
End Sub  

Sub PerformActions() 
    Action1() 
    If Not Action2() Then 
     Abort() 
    End If 
    Action3() 
    ... 
End Sub 

Comment le développeur .NET typique gère-t-il ce cas d'utilisation?

mise à jour:

Pour certaines raisons un certain nombre de personnes vers le bas vote cette question, malheureusement, sans donner aucun commentaire. La seule raison que je peux comprendre est qu'ils pourraient croire que Exception ne devrait jamais être utilisé pour contrôler le flux du programme; et j'ai tendance à être d'accord avec ça. Cependant, j'ai récemment étudié ANTLR et constaté qu'ils utilisent en effet Exception personnalisée (RecognitionException) comme construction de flux de contrôle. Avec l'utilisation de StopIteration de Python, je crois que l'utilisation d'Exception en tant que construction de flux de contrôle est déjà largement utilisée. Ce n'est simplement pas standardisé comme dans Delphi VCL.

Answer 1

Il existe deux qualités qui définissent la classe d'exception EAbort de Delphi.

1. L'IDE est livré pré-configuré pour ne pas interrompre votre programme lorsqu'il détecte une exception étant soulevé de cette classe.
2. Le gestionnaire d'exceptions d'application principal reconnaît EAbort et ses descendants et n'affiche pas la boîte de message habituelle lorsqu'il attrape une telle exception.

Il semble que le code que vous avez proposé accomplisse la deuxième partie. Vous pouvez configurer Visual Studio pour la première partie; reportez-vous à la réponse à une autre question de dépassement de pile, Is there a better way to get Visual Studio to ignore try/catch in debug mode? Je ne connais aucune classe d'exception déjà désignée pour cela.

L'exception EAbort permet au programme d'arrêter l'exécution de tout événement ou gestionnaire de messages qu'il exécute et reprend à la boucle de message principale. Pour que cela fonctionne vraiment, cependant, tout votre autre code doit être écrit pour gérer correctement les exceptions. Autrement dit, ils doivent utiliser les sections finally pour se maintenir dans des états stables et cohérents, et ils doivent soit renvoyer, soit ne jamais attraper des exceptions qu'ils ne sont pas vraiment capables de corriger.

Answer 2

Le seul que je connaisse est ThreadAbortException qui est « L'exception qui est levée lorsqu'un appel est fait à la méthode Abort. »

Answer 3

Si vous voulez quitter une application rapide en .Net est une exception pas le meilleur chemin. Toute exception que vous lancez explicitement peut être interceptée et avalée. Même des exceptions dangereuses comme ThreadAbortException peuvent être interceptées si vous faites les bons tours. La meilleure façon de quitter rapidement une application est d'utiliser Environment.Exit.

Créer ou intentionnellement créer un scénario de débordement de pile car il s'agit d'une exception non détectable lorsqu'il est lancé par le CLR (sans fournir d'hôte personnalisé).

Answer 4

Il s'agit essentiellement d'une exception qui sert simplement de sortie rapide de la fonction. Les exceptions .NET ne sont pas destinées à le faire et les avaler est une mauvaise pratique.

Les exceptions ne doivent pas être utilisées pour gérer le flux de données. Si vous pensez que quelque chose pourrait échouer, vous pouvez lancer une exception, mais l'attraper au premier moment approprié. Laisser l'exception tomber à la fonction UnhandledException et l'avaler est simplement une mauvaise pratique qui pourrait laisser votre application dans un état inconnu (puisque toutes les méthodes par lesquelles l'exception se passe seront "annulées").

Dans ce cas, si vous avez besoin exception dans cette sous, je l'attraper à un appel:

try { 
    PerformActions() 
} catch (AbortProcess) { 
    //do some cleaning up or just ignore 
} 

Cette exception façon est pris près de son origine et tout nettoyage est limitée à cette fonction seulement. Toutes les autres exceptions passeront à votre fonction UnhandledException où la meilleure chose que vous pourriez faire est de signaler une erreur et fermer l'application.