Choix de blocs de capture

Question

Je lis un article sur le C#. Il suggère que

A la fin du bloc de capture, vous avez trois choix :

- Relancer la même exception, en notifiant le code situé plus haut dans la pile d'appels de l'exception.
exception.

_**

- Lancer une exception différente, ce qui donne des informations plus riches sur les exceptions au code situé plus haut dans la hiérarchie. la pile d'appels.

- Laissez le fil tomber du bas du bloc de capture.

**_

Je ne parviens pas à comprendre ces points, il serait très utile que vous les clarifiiez en donnant un exemple simple.

Merci d'avance.

Mise à jour : Lorsque j'ai besoin de gérer une exception rejetée, dois-je avoir des blocs try .. catch imbriqués comme suit

try
{
   try
   {
   }
   catch(InvalidOperationException exp)
   {
     throw;
   }

}
 catch(Exception ex)
 {
    // handle the exception thrown by inner catch block
   // (in this case the "throw"   clause     inside the inner "catch")
 }
}

Answer 1

Vous pouvez également retourner dans le bloc de capture, il y a donc cette 4ème option. Retourner false, retourner null, etc... (même retourner une valeur par défaut.)

Le fait de laisser tomber le bloc catch implique que vous avez traité avec succès l'exception soulevée dans votre bloc try. Si ce n'est pas le cas, il vaut mieux relancer le processus ou échouer d'une autre manière.

Answer 2

Ce n'est pas spécifique à c#, c'est vrai pour tout langage de programmation (appelez-les exceptions, appelez-les erreurs, appelez-les comme vous voulez).

La réponse à votre question est donc qu'il s'agit d'un principe de base de toute programmation et que vous devez déterminer l'action correcte à entreprendre dans votre code, compte tenu de l'erreur, des circonstances et des exigences.

Answer 3

Taylor,

Comme vous vous familiarisez avec le traitement des exceptions, j'aimerais ajouter mon grain de sel. Le lancement d'une exception est très coûteux (coûteux étant bien sûr gourmand en mémoire). Dans ce cas, vous devriez envisager d'assigner le message d'erreur à une chaîne de caractères et de le transmettre à travers l'application vers le journal ou autre.

par exemple :

string errorMessage = string.empty;

try
{
...
}
catch(Exception e)
{
   errorMessage = e.Message + e.StackTrace;;
}

De cette façon, vous pouvez porter cette corde de toute façon. Cette chaîne peut être une propriété globale et peut être envoyée par courriel ou enregistrée dans un fichier texte.

Answer 4

Je pense qu'il y a quelque chose à ajouter aux excellentes réponses que nous avons déjà obtenues ici.

Cela peut faire partie de votre conception architecturale globale (ou non), mais ce que j'ai toujours observé, c'est que l'on n'attrape généralement que lorsque l'on peut ajouter de la valeur (ou récupérer de l'erreur) - en d'autres termes, il ne faut pas essayer...attraper...relancer plusieurs fois pour une seule opération.

Vous devez normalement prévoir un modèle ou une conception cohérente pour le traitement des exceptions dans le cadre de votre conception globale. Vous devez toujours prévoir de gérer les exceptions dans tous les cas, les exceptions non gérées sont laides !