Comment utiliser try catch pour la gestion des exceptions est une bonne pratique

Meilleure pratique est que la gestion des exceptions ne doit jamais cacher les problèmes . Cela signifie que les blocs try-catch devraient être extrêmement rares.

il y a trois circonstances où l'utilisation d'un try-catch a du sens.

1. Toujours traiter avec des connu exceptions aussi bas que vous le pouvez. Toutefois, si vous attendez une exception, il est généralement préférable de tester pour elle premier. Par exemple, la mise en page, le formatage et les exceptions arithmétiques sont presque toujours mieux traités par des contrôles logiques d'abord, plutôt qu'un try-catch spécifique .

2. si vous devez faire quelque chose sur une exception (par exemple, ouvrir une session ou annuler une transaction), relancez l'exception.

3. Toujours traiter avec des inconnu exceptions près aussi haut que vous le pouvez - les seul le code qui devrait consommer une exception et ne pas la relancer devrait être L'UI ou L'API publique.

supposons que vous vous connectiez à une API distante, ici vous savez vous attendre à certaines erreurs( et avoir des choses à faire dans ces circonstances), donc c'est le cas 1:

try 
{
    remoteApi.Connect()
}
catch(ApiConnectionSecurityException ex) 
{
    // User's security details have expired
    return false;
}

return true;

notez qu'aucune autre exception n'est prise, car on ne s'y attend pas.

supposons maintenant que vous essayez de sauver quelque chose à la base de données. Nous devons la faire reculer si elle échoue, donc nous avons le cas 2:

try
{
    DBConnection.Save();
}
catch
{
    // Roll back the DB changes so they aren't corrupted on ANY exception
    DBConnection.Rollback();

    // Re-throw the exception, it's critical that the user knows that it failed to save
    throw;
}

notez que nous rejetons l'exception - le code plus haut doit encore savoir que quelque chose a échoué.

enfin, nous avons L'UI-ici, nous ne voulons pas avoir des exceptions complètement désamorcées, mais nous ne voulons pas les cacher non plus. Voici un exemple du cas 3:

try
{
    // Do something
}
catch(Exception ex) 
{
    // Log exception for developers
    WriteException2LogFile(ex);

    // Display message to users
    DisplayWarningBox("An error has occurred, please contact support!");
}

cependant, la plupart des cadres API ou UI avoir des façons génériques de faire Cas 3. Par exemple: ASP.Net a un écran d'erreur jaune qui vide les détails de l'exception, mais qui peut être remplacé par un message plus générique dans l'environnement de production. Suivre ces règles est une bonne pratique, car cela vous permet d'économiser beaucoup de code, mais aussi parce que la journalisation et l'affichage des erreurs devraient être des décisions de configuration plutôt que des décisions codées en dur.

cela signifie que le cas 1 (exceptions connues) et le cas 3 (manipulation ponctuelle de L'assurance-chômage) présentent tous deux de meilleures tendances. (évitez l'erreur attendue ou passez la manipulation de l'erreur à L'interface utilisateur).

même le cas 2 peut être remplacé par de meilleurs modèles, par exemple portée des transactions ( using blocs qui annulent n'importe quelle transaction non engagée pendant le bloc) rendent plus difficile pour les développeurs d'obtenir le modèle de meilleure pratique tort.

par exemple supposez que vous avez une grande échelle ASP.Net application. La journalisation des erreurs peut se faire via ELMAH , l'affichage d'erreur peut être un ysod informatif localement et un beau message localisé en production. Les connexions aux bases de données peuvent toutes se faire par l'intermédiaire des champs de transaction et des blocs using . Vous n'avez pas besoin d'un seul bloc try-catch .

TL;DR: La meilleure pratique consiste en fait à ne pas utiliser les blocs try-catch .

une exception est une erreur de blocage .

tout d'abord, la meilleure pratique devrait être ne lancez pas d'exceptions pour tout type d'erreur, à moins que ce soit une erreur de blocage .

si l'erreur est bloquant , alors jeter l'exception. Une fois que l'exception est déjà lancée, il n'y a pas besoin de la cacher car c'est exceptionnel; faites-le savoir à l'utilisateur (vous devriez reformater la toute exception à quelque chose d'utile à l'utilisateur dans l'INTERFACE utilisateur).

votre travail en tant que développeur de logiciels est de tenter d'empêcher un cas exceptionnel où un paramètre ou une situation d'exécution peut se terminer dans une exception. C'est-à-dire, les exceptions ne doivent pas être atténuées, mais celles-ci doivent être évitées .

par exemple, si vous savez qu'un certain entier entrée pourrait venir avec un format invalide, utiliser int.TryParse au lieu de int.Parse . Il y a beaucoup de cas où vous pouvez faire cela au lieu de simplement dire "si cela échoue, jetez simplement une exception".

lancer des exceptions coûte cher.

si, après tout, une exception est lancée, au lieu d'écrire l'exception à la bûche une fois qu'elle a été lancée, l'une des meilleures pratiques est de l'attraper dans un gestionnaire d'exception de première chance . Par exemple:

• ASP.NET: Global.ASAX Application_Error
• Autres: AppDomain.Événement de premièrecanceexception .

ma position est que les tentatives/captures locales sont mieux adaptées pour traiter les cas spéciaux où vous pouvez traduire une exception en une autre, ou quand vous voulez "muter" pour un cas très, très, très, très spécial (un bogue de bibliothèque lancer une exception sans rapport que vous devez muet pour contourner tout le bug).

Pour le reste des cas:

• essayez d'éviter les exceptions.
• si ce n'est pas possible: gestionnaires d'exception de première chance.
• ou utiliser un aspect PostSharp (AOP).

répondant à @thewhiteambit sur un commentaire...

@thewhiteambit a dit:

Les Exceptions ne sont pas fatales-les erreurs, ce sont des Exceptions! Parfois, ils ne sont même pas des erreurs, mais de les considérer comme mortelles-erreurs est complètement fausse compréhension de ce que sont les Exceptions.

tout d'Abord, comment une exception ne peut pas être encore une erreur?

• pas de connexion à la base de données => exception.
• format de chaîne de caractères non valide pour analyser à un type quelconque = > exception
• Essayer de parser JSON et tandis que l'entrée n'est pas en fait JSON => exception
• Argument null tout objet a été prévu => exception
• certaines bibliothèques ont un bug => jette une exception inattendue
• il y a une connexion socket et elle est déconnectée. Ensuite, vous essayez d'envoyer un message => exception
• ...

nous pourrions énumérer 1k cas où une exception est lancée, et après tout, n'importe des cas possibles sera une erreur .

une exception est une erreur, parce qu'à la fin de la journée c'est un objet qui collecte des informations de diagnostic -- il a un message et il se produit quand quelque chose va mal.

personne ne ferait une exception quand il n'y a pas de cas exceptionnel. Les Exceptions devraient être erreurs de blocage parce qu'une fois qu'elles sont lancées, si vous n'essayez pas de si vous tombez dans le utilisez try/catch et exceptions pour mettre en œuvre le flux de contrôle cela signifie que votre application/service va arrêter l'opération qui est entrée dans un cas exceptionnel .

aussi, je suggère à tout le monde de vérifier le fail-fast paradigm publié par Martin Fowler (et écrit par Jim Shore) . C'est comme ça que j'ai toujours compris comment gérer les exceptions, même avant d'en arriver là. document il y a quelque temps.

[...] les considérer comme fatales-les erreurs sont une fausse compréhension de ce que sont les exceptions.

habituellement exceptions couper certains flux d'opération et ils sont manipulés pour les convertir en erreurs humaines compréhensibles. Ainsi, il semble qu'une exception est en fait un meilleur paradigme pour traiter les cas d'erreur et travailler dessus pour éviter un plantage complet d'application / service et notifier l'utilisateur/consommateur que quelque chose n'allait pas.

plus de réponses à propos de @thewhiteambit concerns

par exemple dans le cas d'une base de données manquante-connexion le programme pourrait exceptionnellement continuer à écrire dans un fichier local et envoyer le modifications à la base de données une fois qu'elle est disponible à nouveau. Votre invalide Le casting String-to-Number pourrait être essayé à nouveau avec langue-interprétation locale sur Exception, comme vous essayez par défaut La langue anglaise à analyser("1,5") échoue et vous l'essayez avec l'Allemand interprétation encore une fois qui est tout à fait bien parce que nous utilisons virgule au lieu de le point comme séparateur. Vous voyez ces Exceptions ne doivent même pas ils bloquent, ils n'ont besoin que de quelques exceptions.

1. si votre application peut fonctionner hors ligne sans données persistantes à la base de données, vous ne devriez pas utiliser exceptions , comme la mise en œuvre de flux de contrôle en utilisant try/catch est considéré comme un anti-modèle. le travail hors ligne est un cas d'utilisation possible, donc vous implémentez le flux de contrôle pour vérifier si la base de données est accessible ou non, vous n'attendez pas qu'elle soit inaccessible .

2. Le analyse chose est également un cas attendus ( pas EXCEPTIONNEL ). Si vous vous attendez à cela, vous n'utilisez pas d'exceptions pour faire le flux de contrôle! . Vous obtenez des métadonnées de l'utilisateur pour savoir quelle est sa culture et vous utilisez des formateursà cette fin! .NET prend en charge cet environnement et d'autres aussi, et une exception parce que le formatage des nombres doit être évité si vous vous attendez à une utilisation de votre application/service spécifique à une culture .

une Exception non entravée devient généralement une erreur, mais les Exceptions elles-mêmes ne sont pas codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

cet article n'est qu'une opinion ou un point de vue de l'auteur.

puisque Wikipedia peut être aussi juste l'opinion des auteurs d'Articles, Je ne dirais pas que c'est le dogme , mais vérifier ce que codage par exception article dit quelque part dans un paragraphe:

[...] En utilisant ces exceptions pour traiter les erreurs spécifiques qui continuer le programme est appelé codage par exception. cet anti-modèle peut rapidement dégrader le logiciel dans la performance et la maintenabilité.

Il a également dit quelque part:

usage Incorrect d'une exception

Souvent codage par exception peut entraîner d'autres problèmes dans le logiciel avec une exception incorrecte utilisation. En plus d'utiliser l'exception manipulation pour un problème unique, l'utilisation d'une exception incorrecte prend ceci plus loin en exécutant le code même après que l'exception est levée. Ce mauvaise méthode de programmation ressemble à la méthode goto dans de nombreux logiciels langues, mais se produit uniquement après un problème dans le logiciel est détecté.

honnêtement, je crois que le Logiciel ne peut pas être développé ne prenez pas les cas d'utilisation au sérieux. Si vous savez que...

• votre base de données peut être désactivée...
• Certains fichiers peuvent être verrouillés...
• certains formatage pourraient ne pas être pris en charge...
• une validation de domaine peut échouer...
• votre application doit fonctionner en mode déconnecté...
• quel que soit le cas d'utilisation ...

... vous n'utiliserez pas d'exceptions pour ce . Vous support ces cas utilisent le flux de contrôle régulier.

et si un cas d'utilisation inattendue n'est pas couvert, votre code échouera rapidement, parce que il lancera une exception . Oui, parce qu'une exception est un cas exceptionnel .

d'autre part, et enfin, parfois vous couvrez cas exceptionnels lancer exceptions attendues mais on ne les jette pas pour contrôler le flux. Vous le faites parce que vous voulez notifier aux couches supérieures que vous ne supportez pas certains cas d'utilisation ou que votre code ne fonctionne pas avec certains arguments ou données/propriétés d'environnement donnés.

la seule fois où vous devriez inquiéter vos utilisateurs au sujet de quelque chose qui s'est passé dans le code est s'il y a quelque chose qu'ils peuvent ou doivent faire pour éviter le problème. S'ils peuvent modifier des données sur un formulaire, appuyer sur un bouton ou modifier le réglage d'une application afin d'éviter le problème, puis les informer. Mais les avertissements ou les erreurs que l'utilisateur n'a pas la capacité d'éviter juste les fait perdre confiance en votre produit.

les Exceptions et les Logs sont pour vous, le développeur, pas votre fin utilisateur. Comprendre la bonne chose à faire lorsque vous attrapez chaque exception est bien mieux que de simplement appliquer une règle d'or ou de compter sur un filet de sécurité à l'échelle de l'application.

le codage sans esprit est le seul type de mauvais codage. Le fait que vous vous sentez qu'Il ya quelque chose de mieux qui peut être fait dans ces situations montre que vous êtes investi dans un bon codage, mais éviter d'essayer d'estampiller une règle générique dans ces situations et de comprendre la raison de quelque chose à jeter dans le premier endroit et ce que vous pouvez faire pour vous en remettre.

je sais que c'est une vieille question, mais personne ici n'a mentionné l'article de MSDN, et c'est le document qui l'a éclairci pour moi, MSDN a un très bon document sur ce, vous devriez attraper des exceptions quand les conditions suivantes sont vraies:

• vous avez une bonne compréhension de la raison pour laquelle l'exception pourrait être lancée, et vous pouvez mettre en œuvre une récupération spécifique, comme inciter l'utilisateur à entrer un nouveau nom de fichier lorsque vous attrapez un objet FileNotFoundException.

• vous pouvez créer et lancer une nouvelle exception, plus spécifique.

int GetInt(int[] array, int index)
{
    try
    {
        return array[index];
    }
    catch(System.IndexOutOfRangeException e)
    {
        throw new System.ArgumentOutOfRangeException(
            "Parameter index is out of range.");
    }
}

• vous voulez manipuler partiellement une exception avant de la transmettre pour une manipulation supplémentaire. Dans l'exemple suivant, un bloc catch est utilisé pour ajouter une entrée dans un journal d'erreur avant de re-jeter l'exception.

    try
{
    // Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
    // Call a custom error logging procedure.
    LogError(e);
    // Re-throw the error.
    throw;     
}

je suggère de lire la section Exceptions et traitement des exceptions " et aussi meilleures pratiques pour les Exceptions .

la meilleure approche est la seconde (celle dans laquelle vous spécifiez le type d'exception). L'avantage de ceci est que vous savez que ce type d'exception peut se produire dans votre code. Vous vous occupez de ce type d'exception et vous pouvez reprendre. Si une autre exception est venue, alors cela signifie que quelque chose ne va pas qui vous aidera à trouver des bogues dans votre code. L'application finira par planter, mais vous saurez qu'il y a quelque chose que vous avez manqué (bug) qui doit être corrigé.

la deuxième approche est bonne.

si vous ne voulez pas afficher l'erreur et confondre l'utilisateur de l'application en montrant l'exception d'exécution(i.e. l'erreur) qui n'est pas liée à eux, alors il suffit de log error et l'équipe technique peut chercher le problème et le résoudre.

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);//it will write the or log the error in a text file
}

je vous recommande d'y aller pour la deuxième approche pour l'ensemble de votre demande.

laisser le bloc de capture vide est la pire chose à faire. Si il y a une erreur, la meilleure façon de le gérer est de:

1. enregistrer dans le fichier\etc..
2. Essayer de les corriger à la volée (peut-être essayer autre manière de faire cette opération)
3. si nous ne pouvons pas corriger cela, aviser l'utilisateur qu'Il ya une erreur et bien sûr annuler l'opération

pour moi, l'exception de manipulation peut être considérée comme une règle d'affaires. Évidemment, la première approche est inacceptable. La seconde est meilleure et elle pourrait être correcte à 100% si le contexte le dit. Maintenant, par exemple, vous développez un addin Outlook. Si vous ajoutez des lancers unhandled exception, l'utilisateur outlook pourrait maintenant le savoir puisque l'outlook ne se détruira pas lui-même en raison d'un plugin échoué. Et vous avez du mal à comprendre ce qui n'allait pas. Par conséquent, la deuxième approche cas, pour moi, c'est correct. En plus de la journalisation de l'exception, vous pouvez décider d'afficher le message d'erreur à l'utilisateur - je le considère comme une règle d'affaires.

la meilleure pratique consiste à faire une Exception lorsque l'erreur se produit. Car une erreur s'est produite et il ne devrait pas être cachée.

mais dans la vraie vie vous pouvez avoir plusieurs situations quand vous voulez cacher ce

1. vous comptez sur le composant tiers et vous voulez continuer le programme en cas d'erreur.
2. vous avez une analyse de rentabilisation que vous devez poursuivre en cas d'erreur

vous devriez considérer ces lignes directrices de conception pour les Exceptions

• Lancer D'Exception
• Utilisant Les Types D'Exception Standard
• Exceptions et exécution

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions

Le catch sans aucun argument est tout simplement manger l'exception et n'est d'aucune utilité. Que faire si une erreur fatale se produit? Il n'y a aucun moyen de savoir ce qui s'est passé si vous utilisez catch sans argument.

une déclaration de capture devrait attraper plus spécifique Exceptions comme FileNotFoundException et puis à la très fin vous devez attraper Exception qui attraperait toute autre exception et les enregistrer.

parfois, vous devez traiter les exceptions qui ne disent rien aux utilisateurs.

Mon chemin est:

• Pour attraper uncaughted exceptions au niveau de l'application (c'est à dire. mondiale.asax) pour les exceptions critiques (application ne peut pas être utile). Ces exeptions je ne suis pas attraper sur la place. Il suffit de les enregistrer au niveau de l'application et de laisser le système faire son travail.
• attraper "sur place" et montrer quelques informations utiles à l'utilisateur (entré mauvais numéro, ne peut pas analyser.)
• Catch sur place et de ne rien faire sur des problèmes marginaux, comme "je vais vérifier pour mettre à jour les infos sur le fond, mais le service n'est pas en cours d'exécution".

Il n'a certainement pas la meilleure pratique. ;- )

avec des Exceptions, j'essaie ce qui suit:

tout d'abord, j'attrape des types spéciaux d'exceptions comme la division par zéro, les opérations IO, et ainsi de suite et j'écris le code selon cela. Par exemple, une division par zéro, en fonction de la provenance des valeurs, je pourrais alerter l'utilisateur (exemple: une calculatrice simple en ce que dans un calcul du Milieu (pas les arguments) arrive dans une division par zéro) ou pour traiter silencieusement cette exception, en l'enregistrant et en continuant le traitement.

ensuite, j'essaie de saisir les exceptions restantes et de les enregistrer. Si possible, pour permettre l'exécution de code, sinon avertir l'utilisateur qu'une erreur s'est produite et demandez-leur d'envoyer un rapport d'erreur.

en code, quelque chose comme ça:

try{
    //Some code here
}
catch(DivideByZeroException dz){
    AlerUserDivideByZerohappened();
}
catch(Exception e){
    treatGeneralException(e);
}
finally{
    //if a IO operation here i close the hanging handlers for example
}