Explication détaillée de .NET Framework des principes de conception d'exceptions

Frontline

Pour les directives de conception d'exceptions, reportez-vous à Microsoft msdn, combinez votre propre compréhension et la gestion des erreurs d'exception dans le développement passé, résumez l'architecture de développement logiciel et comment mieux concevoir Un ensemble de directives relatives aux erreurs d'exception.

Introduction aux lignes directrices

Concept d'échec d'exécution

La signification de échec d'exécution : l'échec d'exécution se produit chaque fois qu'un membre ne peut pas faire ce qu'il a été conçu pour faire (ce que le nom du membre implique). Par exemple, si la méthode OpenFile ne peut pas renvoyer un descripteur de fichier ouvert à l'appelant, cela sera considéré comme un échec d'exécution.

Traduction :

La signification de l'échec de l'opération : chaque fois qu'un module membre ne peut pas terminer sa tâche attendue, on dit qu'un échec de l'opération s'est produit. Par exemple, la méthode OpenFile ne peut pas renvoyer un handle vers le fichier ouvert à l’appelant, ce qui constitue un échec d’opération.

Gestion des exceptions dans le Framework

Dans le Framework, les exceptions sont utilisées pour toutes les conditions d'erreur, y compris les erreurs d'exécution.

Traduction :

Dans le framework, les exceptions sont utilisées pour gérer toutes les conditions d'erreur, y compris les erreurs d'exécution.

Lignes directrices récapitulatives

Les méthodes qui doivent être interdites lors de la conception d'exceptions, celles qui doivent être faites sans hésitation et celles qui doivent être prises en compte sont répertoriées dans le tableau ci-dessous.

编号	方法	做法
1	返回错误代码	禁止
2	执行错误，要抛出异常；如OpenFile()未返回文件句柄	建议
3	假如代码再继续执行就变得不安全时，考虑是调用System.Environment.FailFast终止进程还是抛异常。	考虑
4	如果有可能的话，在正常的控制流处，抛异常，见下面的分析	禁止
5	抛异常对性能的影响。	考虑
6	协定中纳入异常处理部分	建议
7	将异常作为返回值返回	禁止
8	使用异常生成器方法，为避免代码膨胀, 用helper方法创建异常和属性.	考虑
9	异常筛选器中抛出异常.	禁止
10	从finally 块中显示地抛出异常	禁止

　
　Explication de l'élément 4 :

Dans le codage quotidien, considérez le modèle Tester-Doer pour les membres qui peuvent lever des exceptions dans des scénarios courants pour éviter les problèmes de performances liés aux exceptions. Le modèle Tester-Doer lance un appel qui peut générer des exceptions en deux parties : un testeur et un Doer. Le testeur effectue un test pour l'état qui peut amener le Doer à lever une exception. test est inséré juste avant le code qui lève l'exception, protégeant ainsi contre l'exception. Exemple de référence de http://blog.csdn.net/troubleshooter/article/details/18401491

Code :

Tester et Doer remplissent leurs tâches respectives, réduisant parfaitement les exceptions lancées et améliorant les performances.
Doer : Si la surveillance statut ci-dessus est bonne, elle peut être traitée par DoProcess(); si elle est fausse, et si DoProcess() inclut la logique DoCheck(), une exception sera levée, mais de cette façon Après la séparation, DoProcess() ne lèvera pas d'exception !

if(DoCheck()==true)//这是Tester:状态监测
    DoProcess();

Exceptions courantes et méthodes de gestion dans le développement de logiciels (auto-résumé)

1 Il est recommandé d'envelopper l'interface d'opération exposée par la couche UI dans un essai {}catch{} bloc , l'exception levée dans le catch est écrite sur le disque.

2 Lorsqu'un minuteur est utilisé dans la couche UI, lorsqu'une exception se produit dans la fonction de rappel du compteur, le minuteur doit être arrêté pour empêcher l'écriture du journal des erreurs dans le déposer.

3 Il est recommandé de ne pas envelopper le bloc try{}catch{} dans la couche inférieure Il est recommandé d'utiliser throw pour lancer une exception directement, car le try{} et. Les blocs catch{} sont encapsulés dans la couche UI, il n'y a donc pas besoin d'écrire dans ces couches.

4 throw interrompra directement les opérations futures et passera à la pile externe try{} et catch{}, c'est-à-dire la couche UI. Profitant de cette propriété, il est généralement recommandé que les fonctions le fassent. ne renvoie pas de codes d'erreur.

5 Une exception locale s'est produite lors du traitement des données importées par lots. Excel importe du personnel, des équipements, des plans, des matériaux, des processus, etc. Si une certaine ligne de données enfreint les règles, il n'est pas recommandé de lever une exception à ce stade, car une fois qu'une exception est levée, cela signifie que les données du les lignes suivantes ne peuvent pas être importées et les données importées deviennent des données sales.
Il existe généralement deux approches : les données illégales apparaissent dans une certaine ligne et sont enregistrées dans le fichier journal. Plus tard, sur la base de ce fichier, il s'avère que les données n'ont pas été importées, puis celles-ci peuvent être traitées séparément. ; Avant d'importer, vérifiez directement Après avoir vérifié si les données de toutes les lignes sont légales, importez une par une, sinon une invite apparaîtra et aucune donnée ne sera écrite dans la base de données. Cette dernière approche est généralement recommandée. Cette approche est appelée : Mode d'exception Tester-Doer, qui est également recommandé par Microsoft.

6 Lors du traitement des données d'affichage du tableau de bord, une exception s'est produite localement. Ce mode de traitement est différent de 5. Généralement, lorsqu'une exception se produit à ce moment-là, l'ancienne méthode 5 est souvent adoptée : affiche les données correctes et les données illégales sont écrites dans le journal pour examen  ; mais il est également possible que si les données principales dans l'interface affichée n'existent pas, une exception sera levée directement, écrite dans le journal et résolue via le journal. Par conséquent, elles doivent être traitées en fonction de la gravité des anomalies des données.

7 Sur la base des documents de développement, des journaux et des analyses, essayez de trouver la raison pour laquelle une certaine fonction n'est pas implémentée. Tout d’abord, conservez les documents de développement et vérifiez si les exigences actuelles des utilisateurs sont cohérentes avec celles des documents de développement. S'ils sont cohérents, le rôle du journal sera affiché à ce moment-là. Par exemple, un diagramme circulaire résumant l'achèvement de tous les processus en une semaine. S'il n'y a pas de données de processus, alors le diagramme circulaire peut ne pas exister. processus de développement, s'il est coché, cela ne signifie pas qu'il existe un processus. Si un processus n'est pas trouvé, une exception peut être levée. Si le processus est écrit dans le journal, la raison sera trouvée. Par conséquent, ce type de problème doit également être consigné dans le journal. Bien qu’il ne s’agisse pas d’une erreur, il peut être classé comme exception.

8 La fonction renvoie un objet dont les méthodes et propriétés sont référencées par une logique ultérieure. C'est inévitable ! Et la mise en œuvre de la plupart des fonctions en dépend. Étant donné que l'objet renvoyé sera référencé ultérieurement, est recommandé d'effectuer une comparaison nulle. S'il est nul, doit-il être transmis à la couche d'interface utilisateur et une invite de message apparaîtra, ou une exception sera levée directement. La couche d'interface utilisateur l'écrira dans le journal après le traitement, en fonction de la situation.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!