Plusieurs erreurs courantes en C#/.NET

1 Libérez les ressources rapidement
L'environnement d'hébergement CLR joue le rôle de garbage collection, vous n'avez donc pas besoin de libérer explicitement la mémoire occupée par les objets créés. Mais cela ne signifie pas que vous pouvez ignorer tous les objets utilisés. De nombreux objets encapsulent d'autres types de ressources système (par exemple, fichiers disque, connexions de données, ports réseau). Garder ces ressources utilisées peut considérablement épuiser les ressources du système, nuire aux performances et finalement provoquer des erreurs de programme. Lorsque vous ouvrez un fichier, un port réseau ou une connexion de données, vous devez explicitement libérer les ressources dès que vous ne les utilisez plus.
De plus, pour les opérations sur les ressources, il est généralement nécessaire d'ajouter un traitement de capture d'exception (Try..Catch, n'oubliez pas de libérer la ressource enfin pour vous assurer que la ressource pourra être libérée normalement quand). attraper l'exception.
2 Arrêtez correctement les multi-threads
FileStream fs = File.Open(…);
Essayez{…} Enfin{ fs.Close;}
Supposons que le code ci-dessus se trouve dans le thread de travail et a été traité vers enfin Inside, à ce moment-là, le thread de l'interface utilisateur appelle la méthode Abort() du thread, il est donc très probable que le thread de travail saute hors du bloc de code final avant l'exécution de fs.Close. De cette façon, votre fs ne sera jamais fermé.
Dans la plupart des cas, final sera exécuté pour toujours, mais n'inclut pas l'exception ThreadAbort levée en appelant Thread.Abort. Pour cette raison, il n'est pas recommandé d'utiliser Abort.
Pour arrêter correctement un thread, cela ne dépend pas du comportement de l'appelant (n'utilisez pas Thread.Abort() directement), mais plutôt de la capacité du thread de travail à répondre activement à la demande d'arrêt de l'appelant.
Le mécanisme général est que si le thread doit être arrêté, alors le thread lui-même doit être responsable de l'ouverture de l'interface Cancel à l'appelant.
3 Liés à la conversion de type
Si une valeur est lue dans la base de données, elle sera de type int lorsqu'il y a des données. S'il n'y a pas de données, elle sera nulle. Si le type est forcé, une exception sera. se produire. Par conséquent, le transfert forcé est rarement utilisé. S'il est utilisé, une exception doit être interceptée pour éviter les exceptions du programme.
Dans le cas où le transfert forcé n'est pas bon, nous vous recommandons d'utiliser la méthode TryParse, qui a déjà implémenté la gestion des exceptions pour la méthode Parse.
Vous pouvez également utiliser Convert, qui nécessite également la capture d'exceptions ; en fait, partout où la conversion de type, la sérialisation et d'autres opérations sont impliquées, des exceptions doivent être interceptées
4 Problèmes d'opération de chaîne
Dans les opérations de chaîne, si ; un grand nombre d'opérations d'épissage sont impliquées, il est recommandé d'utiliser StringBuilder. Si vous utilisez String, il y aura des pertes de performances évidentes. La raison en est que l'objet chaîne est un objet très spécial et ne peut pas être modifié une fois qu'une valeur lui a été attribuée. L'appel d'une opération d'épissage (telle qu'une affectation, "+", etc.) dans la classe String au moment de l'exécution créera un nouvel objet chaîne dans la mémoire, ce qui signifie également qu'un nouvel espace mémoire doit être alloué pour le nouvel objet.
5 Problèmes causés par la modification de la constante const
Faites particulièrement attention lorsque le programme fait référence à des constantes const dans d'autres DLL.
Si vous modifiez la constante const dans cette dll, vous devez recompiler tous les programmes qui référencent cette constante const dans cette dll, sinon la valeur constante utilisée dans le programme sera incohérente avec la valeur dans la dl.
De plus, si vous utilisez readonly au lieu de const, vous pouvez résoudre ce problème sans recompiler, car const est une constante compilée et readonly est une constante d'exécution.
6 Problèmes de plate-forme cible de compilation C#
Lorsque la DLL dont dépend le programme est compilée sur une plate-forme cible de X86, la plate-forme cible de compilation du programme lui-même doit également être impossible à exécuter.
7 Contrôle d'accès cross-thread
Lors du développement de programmes d'interface, vous rencontrerez des opérations fastidieuses. Pour la convivialité du programme, nous effectuons généralement des opérations fastidieuses dans le thread de tâche et affichons les informations d'exécution dans Main. Fil de discussion de l'interface utilisateur.
Si vous utilisez directement les contrôles dans le thread principal de l'interface utilisateur dans le thread de tâche, il est très facile de provoquer une exception et de signaler "la valeur du thread qui a créé le contrôle ne peut pas être modifiée dans d'autres threads". défini pour interdire au compilateur de vérifier l'accès entre threads, aucune erreur ne sera signalée, mais des problèmes imprévisibles se produiront. À l’heure actuelle, il est recommandé d’utiliser la délégation ou la délégation anonyme.

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!