Comment utiliser try catch pour la gestion des exceptions est la meilleure pratique

Question

tout en conservant le code de mon collègue même de la part de quelqu'un qui prétend être un développeur senior, je vois souvent le code suivant:

try
{
  //do something
}
catch
{
  //Do nothing
}

ou parfois ils écrivent des informations de journalisation dans des fichiers journaux comme suit le bloc try catch 

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);
}

Je me demande simplement si ce qu'ils ont fait est la meilleure pratique? Cela me rend perplexe car, à mon avis, les utilisateurs devraient savoir ce qui se passe avec le système.

S'il vous plaît donnez-moi un conseil.

Answer 1

Ma stratégie de traitement des exceptions est la suivante:

• Pour attraper toutes les exceptions non gérées en se connectant au Application.ThreadException event, puis décidez:

  • Pour une application d'interface utilisateur: pour qu'il apparaisse à l'utilisateur avec un message d'excuses (winforms)
  • Pour un service ou une application console: enregistrez-le dans un fichier (service ou console)

Ensuite, je joins toujours chaque morceau de code exécuté en externe dans try/catch:

• Tous les événements déclenchés par l'infrastructure Winforms (Load, Click, SelectedChanged ...)
• Tous les événements déclenchés par des composants tiers

Ensuite, je joins à 'essayer/attraper'

• Toutes les opérations que je sais ne fonctionneront peut-être pas tout le temps} (opérations IO, calculs avec une division de zéro potentielle ...) Dans un tel cas, je lance une nouvelle ApplicationException("custom message", innerException) pour suivre ce qui s'est réellement passé

De plus, je fais de mon mieux pour trier les exceptions correctement. Il y a des exceptions qui:

• besoin d'être montré à l'utilisateur immédiatement
• nécessite un traitement supplémentaire pour assembler les éléments lorsqu'ils surviennent afin d'éviter les problèmes en cascade (par exemple: mettez .EndUpdate dans la section finally pendant un remplissage TreeView)

• l'utilisateur s'en fiche, mais il est important de savoir ce qui s'est passé. Alors je les connecte toujours:

  • Dans le journal des événements
  • ou dans un fichier .log sur le disque

Il est recommandé de concevoir des méthodes statiques pour gérer les exceptions dans les gestionnaires d'erreur de niveau supérieur de l'application.

Je me force aussi à essayer de:

• Rappelez-vous TOUTES les exceptions sont remontées jusqu'au niveau supérieur. Il n'est pas nécessaire de placer les gestionnaires d'exceptions partout.
• Les fonctions réutilisables ou appelées en profondeur n'ont pas besoin d'afficher ni de consigner les exceptions: elles sont soit automatiquement condensées, soit extraites de nouveau avec certains messages personnalisés dans mes gestionnaires d'exceptions.

Alors finalement:

Mal:

// DON'T DO THIS, ITS BAD
try
{
    ...
}
catch 
{
   // only air...
}

Inutile:

// DONT'T DO THIS, ITS USELESS
try
{
    ...
}
catch(Exception ex)
{
    throw ex;
}

Avoir un essai enfin sans prise est parfaitement valable:

try
{
    listView1.BeginUpdate();

    // If an exception occurs in the following code, then the finally will be executed
    // and the exception will be thrown
    ...
}
finally
{
    // I WANT THIS CODE TO RUN EVENTUALLY REGARDLESS AN EXCEPTION OCCURED OR NOT
    listView1.EndUpdate();
}

Ce que je fais au plus haut niveau:

// i.e When the user clicks on a button
try
{
    ...
}
catch(Exception ex)
{
    ex.Log(); // Log exception

    -- OR --

    ex.Log().Display(); // Log exception, then show it to the user with apologies...
}

Ce que je fais dans certaines fonctions appelées:

// Calculation module
try
{
    ...
}
catch(Exception ex)
{
    // Add useful information to the exception
    throw new ApplicationException("Something wrong happened in the calculation module :", ex);
}

// IO module
try
{
    ...
}
catch(Exception ex)
{
    throw new ApplicationException(string.Format("I cannot write the file {0} to {1}", fileName, directoryName), ex);
}

Il y a beaucoup à faire avec la gestion des exceptions (Custom Exceptions), mais ces règles que j'essaie de garder à l'esprit sont suffisantes pour les applications simples que je fais.

Voici un exemple de méthodes d'extensions permettant de gérer les exceptions capturées de manière confortable. Ils sont mis en œuvre de manière à pouvoir être chaînés et il est très facile d'ajouter votre propre traitement des exceptions interceptées.

// Usage:

try
{
    // boom
}
catch(Exception ex)
{
    // Only log exception
    ex.Log();

    -- OR --

    // Only display exception
    ex.Display();

    -- OR --

    // Log, then display exception
    ex.Log().Display();

    -- OR --

    // Add some user-friendly message to an exception
    new ApplicationException("Unable to calculate !", ex).Log().Display();
}

// Extension methods

internal static Exception Log(this Exception ex)
{
    File.AppendAllText("CaughtExceptions" + DateTime.Now.ToString("yyyy-MM-dd") + ".log", DateTime.Now.ToString("HH:mm:ss") + ": " + ex.Message + "\n" + ex.ToString() + "\n");
    return ex;
}

internal static Exception Display(this Exception ex, string msg = null, MessageBoxImage img = MessageBoxImage.Error)
{
    MessageBox.Show(msg ?? ex.Message, "", MessageBoxButton.OK, img);
    return ex;
}

Answer 2

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

Il y a 3 circonstances dans lesquelles utiliser un try-catch est logique.

1. Traitez toujours les exceptions notifiées le plus en profondeur possible. Cependant, si vous attendez une exception, il est généralement préférable de la tester en premier. Par exemple, les exceptions d'analyse, de formatage et d'arithmétique sont presque toujours mieux gérées par des contrôles logiques d'abord, plutôt que par un try-catch spécifique.

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

3. Traitez toujours les exceptions unknown le plus haut possible - le code only qui devrait consommer une exception et ne pas être relu devrait être l'interface utilisateur ou l'API publique.

Supposons que vous vous connectiez à une API distante, vous savez ici qu'il faut s'attendre à certaines erreurs (et avoir des problèmes à ce sujet dans ces circonstances), c'est donc 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 interceptée, car elles ne sont pas attendues.

Supposons maintenant que vous essayez de sauvegarder quelque chose dans la base de données. Nous devons l'annuler s'il échoue, nous avons donc 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 relançons l'exception: le code supérieur doit encore savoir que quelque chose a échoué.

Enfin, nous avons l'interface utilisateur - ici, nous ne voulons pas avoir d'exceptions complètement non gérées, mais nous ne voulons pas les cacher non plus. Nous avons ici 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 frameworks d'API ou d'UI ont des façons génériques de faire le cas 3. Par exemple, ASP.Net a un écran d'erreur jaune qui affiche les détails de l'exception, mais qui peut être remplacé par un message plus générique dans l'environnement de production. Il est recommandé de les suivre car cela vous épargne beaucoup de code, mais aussi parce que la journalisation et l'affichage des erreurs doivent être des décisions de configuration plutôt que codées en dur.

Cela signifie que les cas 1 (exceptions connues) et 3 (traitement de l'interface utilisateur unique) ont tous deux de meilleurs modèles (éviter l'erreur attendue ou la gestion des erreurs manuelles vers l'interface utilisateur).

Même le cas 2 peut être remplacé par de meilleurs modèles, par exemple étendues de transaction ((les blocs using qui annulent toute transaction non validée pendant le bloc) empêchent les développeurs d'obtenir le modèle de meilleure pratique erroné. 

Par exemple, supposons que vous ayez une application ASP.Net à grande échelle. La consignation des erreurs peut se faire via ELMAH , l’affichage des erreurs peut être un YSoD informatif local et un message Nice localisé en production. Les connexions à la base de données peuvent toutes se faire via des portées 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 du tout les blocs try-catch.

Answer 3

Une exception est un erreur bloquante.

Tout d’abord, la meilleure pratique devrait être ne lève pas d’exception pour tout type d’erreur, sauf s’il s’agit d’une erreur bloquante.

Si l'erreur est blocage, alors lève l'exception. Une fois que l'exception est déjà levée, il n'est pas nécessaire de la masquer car c'est exceptionnel; informez-en l'utilisateur (vous devez reformater toute l'exception en un élément utile à l'utilisateur dans l'interface utilisateur).

En tant que développeur de logiciels, votre travail consiste à éviter un cas exceptionnel dans lequel une situation de paramètre ou d'exécution peut se terminer par une exception. Autrement dit, les exceptions ne doivent pas être désactivées, mais doivent être évitées .

Par exemple, si vous savez que certaines entrées entier peuvent avoir un format non valide, utilisez 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, lancez simplement une exception".

Lancer des exceptions coûte cher.

Si, après tout, une exception est générée, au lieu d'écrire l'exception dans le journal une fois qu'il a été généré, l'une des meilleures pratiques consiste à l'attraper dans un gestionnaire d'exception de la première chance. Par exemple:

• ASP.NET: Global.asax Application_Error
• Autres: événement AppDomain.FirstChanceException .

Ma position est que les tentatives/captures locales conviennent mieux à la gestion des cas particuliers dans lesquels vous pouvez traduire une exception en une autre, ou lorsque vous souhaitez la "muter" pour un cas très, très, très, très, très particulier (un bug de bibliothèque en lançant une exception non liée que vous devez désactiver pour contourner le bogue entier).

Pour le reste des cas:

• Essayez d'éviter les exceptions.
• Si cela n'est pas possible: gestionnaires d'exception de la première chance.
• Ou utilisez un aspect PostSharp (AOP).

Répondre à @thewhiteambit sur un commentaire ...

@thewhiteambit a dit:

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

Tout d’abord, comment une exception ne peut même pas être une erreur?

• Aucune connexion à la base de données => exception.
• Format de chaîne non valide pour analyser un type => exception
• Essayer d'analyser JSON et alors que l'entrée n'est pas réellement JSON => exception
• Argument null tant que l'objet était attendu => exception
• Certaines bibliothèques ont un bug => lève une exception inattendue
• Il y a une connexion de socket et il est déconnecté. Ensuite, vous essayez d'envoyer un message => exception
• ...

Nous pourrions lister 1k cas de quand une exception est levée, et après tout, tous les cas possibles seront ne erreur.

Une exception est ​​une erreur, car à la fin de la journée, il s'agit d'un objet qui collecte des informations de diagnostic. Il contient un message et il se produit lorsque quelque chose ne va pas.

Personne ne lancerait une exception s'il n'y a pas de cas exceptionnel. Les exceptions devraient être erreurs de blocage car une fois lancées, si vous n'essayez pas de tomber dans le tilisez try/catch et les exceptions pour implémenter un flux de contrôle, cela signifie que votre application/service arrêtera l'opération entrée dans un cas exceptionnel.

Aussi, je suggère à chacun de vérifier le fail-fast ​​paradigme publié par Martin Fowler (et écrit par Jim Shore) . C’est ainsi que j’ai toujours compris comment gérer les exceptions, même avant d’avoir ce document il ya quelque temps.

[...] considérez-les Fatal-Errors est une compréhension complètement fausse de ce que sont les exceptions.

Habituellement, des exceptions cut ​​certains flux d’opérations et elles sont gérées de manière à les convertir en erreurs compréhensibles par l’homme. Ainsi, il semble qu’une exception constitue en fait un meilleur paradigme pour gérer les erreurs et les résoudre, afin d’éviter un blocage complet de l’application/du service et pour avertir l’utilisateur/consommateur que quelque chose ne va pas.

Plus de réponses à propos de @thewhiteambit

Par exemple, dans le cas d'une connexion de base de données manquante, le programme pourrait exceptionnellement continuer à écrire dans un fichier local et envoyer les modifications à la base de données une fois qu'il sera à nouveau disponible. Vous pouvez essayer de réanalyser votre conversion de chaîne en nombre invalide avec l'interprétation locale dans Exception, comme si vous essayiez d'utiliser l'anglais comme langue par défaut. Parse ("1,5") échoue et essayez à nouveau avec l'interprétation en allemand, qui est complètement bien parce que nous utilisons une virgule au lieu d'un point comme séparateur. Vous voyez que ces exceptions ne doivent même pas être bloquantes, elles nécessitent seulement un traitement d'exception.

1. Si votre application peut fonctionner hors ligne sans persister dans la base de données, vous ne devez pas utiliser exceptions, car l'implémentation du flux de contrôle à l'aide de try/catch est considérée comme un anti-modèle. Le travail hors ligne étant un cas d'utilisation possible, vous implémentez un 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. La chose analyse est également un cas attendu ( pas un cas exceptionnel ). Si vous vous attendez à cela, , vous n'utilisez pas d'exceptions pour contrôler le flux! . Vous obtenez des métadonnées de l'utilisateur pour savoir quelle est sa culture et vous utilisez des outils de formatage pour cela! . NET prend également en charge cet environnement et d'autres, ainsi qu'une exception car le formatage des nombres doit être évité si vous prévoyez une utilisation de votre application/service spécifique à la culture .

Une exception non prise en charge devient généralement une erreur, mais les exceptions en elles-mêmes ne sont pas codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

Cet article est juste un avis ou un point de vue de l'auteur.

Puisque Wikipedia peut n'être que l'opinion des auteurs d'articule, je ne dirais pas que c'est le dogme, mais vérifiez quoi [Codage par exception = article dit quelque part dans un paragraphe:

[...] L'utilisation de ces exceptions pour gérer des erreurs spécifiques lors de la poursuite du programme est appelée codage par exception. Cet anti-motif peut rapidement dégrader les performances et la maintenabilité du logiciel.

Il dit aussi quelque part:

Utilisation d'exception incorrecte

Le codage par exception peut souvent entraîner des problèmes supplémentaires dans le logiciel avec une utilisation incorrecte des exceptions. En plus d'utiliser la gestion des exceptions pour un problème unique, une utilisation incorrecte des exceptions va plus loin en exécutant du code même après le déclenchement de l'exception. Cette méthode de programmation médiocre ressemble à la méthode goto dans de nombreux langages logiciels, mais ne se produit qu'après la détection d'un problème dans le logiciel.

Honnêtement, je pense que les logiciels ne peuvent pas être développés, mais ne prennent pas les cas d'utilisation au sérieux. Si tu le sais ...

• Votre base de données peut être déconnectée ...
• Certains fichiers peuvent être verrouillés ...
• Certaines mises en forme peuvent ne pas être prises en charge ...
• Certaines validations de domaines peuvent échouer ...
• Votre application devrait fonctionner en mode hors connexion ...
• quel que soit le cas d'utilisation ...

... vous n'utiliserez pas d'exceptions pour cela . Vous prendriez en charge ces cas d'utilisation à l'aide d'un flux de contrôle régulier.

Et si certains cas d'utilisation imprévus ne sont pas couverts, votre code échouera rapidement, car une exception sera émise. Oui, car une exception est un cas exceptionnel.

D'autre part, et finalement, vous couvrez parfois cas exceptionnels en lançant les exceptions attendues , mais vous ne les jetez pas à mettre en œuvre le flux de contrôle. Vous le faites parce que vous souhaitez 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.

Answer 4

Je sais que c’est une vieille question, mais personne ici n’a mentionné l’article MSDN, et c’est le document qui m’a éclairci pour le dire, MSDN a un très bon document à ce sujet, vous devriez intercepter des exceptions lorsque sont vrai:

• Vous comprenez bien pourquoi l'exception peut être levée et vous pouvez implémenter une récupération spécifique, par exemple en invitant l'utilisateur à entrer un nouveau nom de fichier lorsque vous interceptez 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 souhaitez gérer partiellement une exception avant de la transmettre pour une gestion supplémentaire. Dans l'exemple suivant, un bloc catch est utilisé pour ajouter une entrée à un journal des erreurs avant de relancer 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èrerais de lire la section " Exceptions et gestion des exceptions " dans son intégralité ainsi que Meilleures pratiques pour les exceptions .

Answer 5

Le seul moment où vous devriez inquiéter vos utilisateurs à propos de quelque chose qui s'est passé dans le code est s'ils peuvent ou doivent faire quelque chose pour éviter le problème. S'ils peuvent modifier les données d'un formulaire, appuyez sur un bouton ou modifiez un paramètre d'application pour éviter le problème, puis informez-les. Mais des avertissements ou des erreurs que l’utilisateur n’a aucune possibilité d’éviter lui font tout simplement perdre confiance en votre produit. 

Les exceptions et les journaux sont pour vous, le développeur, pas pour l'utilisateur final. Comprendre ce qu'il convient de faire lorsque vous interceptez chaque exception est bien mieux que d'appliquer une règle d'or ou de compter sur un filet de sécurité couvrant l'ensemble de l'application.

Le codage sans mental est le SEUL genre de codage incorrect. Le fait de penser que quelque chose de mieux peut être fait dans ces situations montre que vous êtes investi dans une bonne programmation, mais évitez d’essayer d’imposer une règle générique dans ces situations et de comprendre la raison pour laquelle vous voulez lancer quelque chose en premier lieu. vous pouvez faire pour vous en remettre.

Answer 6

La meilleure approche est la seconde (celle dans laquelle vous spécifiez le type d'exception). L'avantage est que vous savez que ce type d'exception peut se produire dans votre code. Vous gérez ce type d'exception et vous pouvez le reprendre. Si une autre exception survient, cela signifie que quelque chose ne va pas, ce 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 oublié (bogue) qui doit être corrigé.

Answer 7

La deuxième approche est bonne.

Si vous ne souhaitez pas afficher l'erreur et confondre l'utilisateur de l'application en affichant une exception d'exécution (erreur) qui ne lui est pas liée, il suffit de consigner l'erreur et l'équipe technique peut rechercher 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’utiliser la deuxième approche pour l’ensemble de votre application.

Answer 8

La meilleure pratique consiste à lancer une exception lorsque l'erreur se produit. Parce qu'une erreur s'est produite et qu'elle ne doit pas être cachée.

Mais dans la vie réelle, vous pouvez avoir plusieurs situations lorsque vous souhaitez masquer cette

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

Answer 9

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

1. Connectez-le dans le fichier\base de données, etc.
2. Essayez de le réparer à la volée (peut-être en essayant une autre façon de faire cette opération)
3. Si nous ne pouvons pas résoudre ce problème, informez l'utilisateur qu'il y a une erreur et abandonnez bien sûr l'opération.

Answer 10

Je peux te dire quelque chose:

Le fragment n ° 1 n'est pas acceptable car il ignore l'exception. (c'est l'avaler comme si rien ne s'était passé).

Donc, n’ajoutez pas de bloc catch qui ne fait rien ou qui ne fait que retoucher.

Le bloc de capture devrait ajouter de la valeur. Par exemple, message de sortie à l'utilisateur final ou erreur de journal.

N'utilisez pas d'exception pour la logique du programme de flux normal. Par exemple:

par exemple validation d'entrée. <- Ceci n'est pas une situation exceptionnelle valide. Vous devez plutôt écrire la méthode IsValid(myInput); pour vérifier si l'élément d'entrée est valide ou non.

Code de conception pour éviter les exceptions. Par exemple:

int Parse(string input);

Si nous transmettons une valeur qui ne peut pas être analysée en int, cette méthode lève une exception, à la place, nous pourrions écrire quelque chose comme ceci:

bool TryParse(string input,out int result); <- cette méthode renverrait un booléen indiquant si l'analyse a abouti.

C'est peut-être un peu en dehors de la portée de cette question, mais j'espère que cela vous aidera à prendre les bonnes décisions quand il s'agit de try {} catch(){} et d'exceptions.

Answer 11

Parfois, vous devez traiter des exceptions qui ne disent rien aux utilisateurs.

Mon chemin est:

• Attraper les exceptions non capturées au niveau de l'application (c'est-à-dire dans global.asax) pour les exceptions critiques (l'application ne peut être utile). Ces exceptions je ne suis pas attrapé sur la place. Il suffit de les connecter au niveau de l'application et de laisser le système faire son travail.
• Catch "sur place" et montrer des informations utiles à l'utilisateur (nombre erroné entré, ne peut pas analyser).
• Catch on Place et ne faites rien sur les problèmes marginaux comme "Je vérifierai les informations de mise à jour sur le fond, mais le service ne fonctionne pas".

Cela ne doit certainement pas être la meilleure pratique. ;-)

Answer 12

Avec Exceptions, j'essaie les solutions suivantes:

Tout d’abord, j’attrape des types spéciaux d’exceptions comme la division par zéro, les opérations IO, etc., et écris du code en fonction de cela. Par exemple, une division par zéro, en fonction de la provenance des valeurs, je pourrais alerter l'utilisateur (par exemple, une calculatrice simple dans laquelle, dans un calcul intermédiaire (pas les arguments), une division par zéro arrive) et continuez le traitement.

Ensuite, j'essaie d'attraper les exceptions restantes et de les consigner. Si possible, autorisez l'exécution du code, sinon, avertissez l'utilisateur qu'une erreur s'est produite et demandez-lui de lui envoyer un rapport d'erreur.

Dans le code, quelque chose comme ceci:

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
}

Answer 13

Pour moi, la gestion des exceptions peut être considérée comme une règle de gestion. De toute évidence, la première approche est inacceptable. Le second est meilleur et il pourrait être correct à 100% SI le contexte le dit. Maintenant, par exemple, vous développez un complément Outlook. Si vous ajoutez une exception non gérée, l'utilisateur Outlook peut maintenant la connaître car Outlook ne se détruira pas car un plugin a échoué. Et vous avez du mal à comprendre ce qui ne va pas. Par conséquent, la deuxième approche dans ce cas, pour moi, est la bonne. Outre la journalisation de l'exception, vous pouvez décider d'afficher un message d'erreur à l'utilisateur. Je le considère comme une règle de gestion.

Answer 14

Vous devriez considérer ces directives de conception pour les exceptions

• Lancer d'exception
• Utilisation de types d'exception standard
• Exceptions et performances

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

Answer 15

La catch sans aucun argument est simplement eating l'exception et ne sert à rien. Et 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 catch devrait capturer plus spécifique Exceptions comme FileNotFoundException, puis à la fin de - /, vous devriez intercepter Exception qui capturera toute autre exception et les enregistrera.