J'ai cherché une réponse à ma question mais je n'ai pas pu en trouver un. Toutes mes excuses si la réponse est là et je suis duplication!
Je continue à voir un code d'essai / attraper comme ..... qui entraînera une avertissement ex n'est jamais utilisé. Donc, ma question est ... Bien que EX n'est jamais utilisé, existe-t-il un avantage dans la déclaration? On m'a dit que peut-être que cela ajoute des détails à la trace de la pile? Parfois, je vois attraper (exception) qui arrête l'avertissement, mais quels avantages cela apportent, le cas échéant? Si je devais écrire cela et ne pas utiliser l'exception de quelque manière que ce soit, je ne déclarerais pas ... pas un gros problème, mais ce serait bien de savoir pour Bien sûr! merci Fred
8 Réponses :
Vous pouvez utiliser cette variable supposons que vous souhaitez vous connecter à votre exception, de sorte que plus tard le développeur Peut jeter un coup d'œil au journal et déterminer ce qui s'est mal passé. Dans ce cas, pour vos questions: Bien que EX n'est jamais utilisé, existe-t-il un avantage dans la déclaration?
Si vous n'allez pas utiliser, alors aucun avantage à la déclarer. On m'a dit que cela ajoute-t-il plus de détails à la trace de la pile?
Je ne suis pas sûr, mais je pense que ce n'est pas le cas. Si vous définissez un, alors cela contiendra la trace de la pile de l'exception, mais cela ne l'ajoutera rien. Parfois, je vois attraper (exception) qui arrête l'avertissement, mais quoi
Les avantages que cela apportent, le cas échéant?
Si vous souhaitez jeter l'exception en utilisant le mot-clé , vous pouvez utiliser EX pour une utilisation ultérieure, y compris la journalisation, la messagerie, etc. EX conserve tous les détails nécessaires requis pour la journalisation. par exemple. StackTrace, message, InnerException Nul, etc.
attraper (exception)
Désolé peut-être que j'aurais dû dire. Je comprends pourquoi vous auriez la déclaration et les différents types d'exceptions que vous pouvez attraper. Ce que je ne sais pas, c'est s'il y a un avantage à la déclaration si vous n'allez pas l'utiliser. Cela me semble inutile mais y a-t-il quelque chose que je manque?
Non, il ne sert à rien de le déclarer sauf si vous l'utilisez réellement.
La suppression des exceptions est généralement une forme de mauvaise forme ... laissez-les parcourir la pile.
concernant "ajoute des détails", reportez-vous à l'exception en utilisant voir: quel est le bonne façon de ré-jeter une exception en C #?
Voir aussi: " Retour aux basiques - Exceptions " lancer pour préserver la trace de la pile, sinon vous les perdre les détails . Encore une fois, l'alternative est là pour ne pas l'attraper du tout. Si vous n'avez pas d'utilisation pour l'exception (récupération, détendez-vous, etc.), il y a des chances qu'il n'y a pas de bonne raison de l'attraper.
Il est important de noter qu'il y a une différence dans vos deux blocs de code posté. Si vous souhaitez éviter votre avertissement de compilateur sans changer le comportement du code, ou si vous le souhaitez. Pour éviter l'avertissement tout en attrapant toujours un type d'exception spécifique, vous pouvez l'utiliser à la place: la prestation ici est que vous pouvez être spécifique: Peu importe, déclarant que l'exception n'ajoute rien aux informations (trace de pile ou autrement) , sauf si vous envisagez explicitement l'exception. (Incidemment, n'utilisez pas attrape (exception ex) attrapera uniquement des exceptions définies par le CLR (ceux qui dérivent de exception ). attraper seul attrapera quelque chose - y compris des exceptions non gérées que le CLR n'a pas pris ni enveloppé ni enveloppé. attrape (sqlineception) , par exemple. Si vous n'utilisez pas la variable, déclarez-vous donner l'avertissement, mais le comportement spécifique au type est toujours utile. jetez ex à rethrow, car il fait perdre des informations: il suffit d'utiliser lancer .)
Si vous ne voulez vraiment rien faire avec exception, vous pouvez également faire pour éviter le compilateur AVERTISSEMENT:
catch (Exception)
{
// Stick our head in the sand
}
Vous pouvez utiliser le motif suivant, déclarant toujours le type d'exception spécifique, sans variable, afin de garantir la manipulation structurée d'exception (SEH) est toujours disponible:
try
{
//Do whatever
}
catch (IOException)
{
MessageBox.Show("Oops, something went wrong in the IO!");
}
catch (Exception)
{
MessageBox.Show("Oops, something went wrong!");
}
Je n'avais aucune idée que vous pouviez attraper une exception sans avoir à l'attribuer à une variable (par exemple, «IoException EX») jusqu'à ce que je rencontre cela. Merci!
Tout sur le développeur et sa capacité à mettre en œuvre une journalisation / débogage correcte dans un terme ultérieur ...
Ceci: pourrait facilement être converti en < / p> Parfois, il est simplement là pour débogage lorsque vous exécutez la ligne par ligne et que vous pouvez avoir un point de rupture sur le Il a son utilité, mais, à l'heure compilée, si vous ne l'utilisez pas, Encore la page Choix du programmateur, et ... une variable inutilisée n'est pas si problématique sur un programme de fin. MessageBox.show ligne et lisez la variable ex . EX est déclarée et non utilisée, vous pouvez donc suivre tous ceux qui le loger et le retirer ou le supprimer.
L'exception comme de la documentation de MSDN:
Si vous voulez ré-jeter l'exception actuellement traitée par un
clause de saisie des paramètres, utilisez la déclaration de lancer sans
Arguments.
http://msdn.microsoft. com / fr-US / bibliothèque / 0YD65ESW% 28v = vs.0% 29.aspx ex qui sera la référence à l'objet d'exception d'exécution peut donner plusieurs avantages. Vous-même comme un développeur peut vous connecter dans un fichier texte ou envoyer un rapport à vous-même.
Vous voulez probablement écrire l'exception réelle à un journal afin que vous puissiez le déboguer plus tard, même si vous ne l'indiquez jamais à l'utilisateur.
Oui si vous n'êtes pas intéressé par ce qui a mal tourné (à vous), vous pouvez le faire de ne pas déclarer l'exception
Puisque vous pouvez avoir plusieurs
attraper es, vous pouvez ainsi écrireattraper (badformatexception) {/ * format mauvais ici * /} catch (exception ex) {/ * erreur inconnue ici * /} < / code>. Je pense que ce serait une raison d'utiliserattraper (exception)Les deux échantillons sont une forme médiocre. Ceci est «code de démonstration», n'utilisez pas dans de vraies applications.