J'ai le code C # suivant. Chaque fois qu'une exception est capturée, disons à la ligne 1, je ne suis jamais capable d'atteindre d'autres lignes (2, 3, 4, etc.).
try
{
line1
line2
...
}
catch (Exception ex)
{
...
}
13 Réponses :
Vous pouvez envelopper juste la ligne 1 dans un bloc de capture d'essai.
Il suffit de mettre un coup d'œil autour de la ligne1
try
{
try
{
line1
}
catch (Exception ex)
{
...
}
line2
...
}
catch (Exception ex)
{
...
}
Cela créera plus de maux de tête qu'il ne résoudra à long terme.
Je suis d'accord que ce n'est pas toujours la meilleure solution, mais il y a des moments où vous devez continuer. Tels que lorsque vous créez une commande et une erreur dans le processus de création de commande. Ce serait une bonne idée de faire un coup d'œil sur des blocs qui ont une possibilité de casser. De cette façon, vous pouvez toujours obtenir toutes les informations de la commande et votre client n'aura pas à recréer complètement la commande.
Et si cela échoue à la ligne 2 Suivant - continuez simplement à manger des exceptions jusqu'à ce que le code finisse de fonctionner?
Affiche dit qu'il échoue "dire à la ligne 1" - un plan de traitement des exceptions bien pensé serait un meilleur conseil à mon avis.
@Davy je suis d'accord avec vous. Je dis simplement que vous devez parfois continuer à traiter. La commande est le meilleur exemple que je puisse penser. Plus vous connaissez des informations sur leur commande, plus il est facile de découvrir comment l'erreur s'est produite et fonctionnait une solution. Et peut-être même réparer leur ordre afin qu'ils ne soient pas à recréer à nouveau.
@Davy Si c'est la situation la première chose à faire, c'est regarder son code et repenser ce qu'il fait. Je disais juste que c'est une option et il devrait être utilisé avec parcimonie.
Les exceptions ne doivent pas être ignorées. :)
Ils existent et sont lancés pour une raison: une situation exceptionnelle s'est produite, une certaine condition n'est pas remplie et je ne peux pas continuer à travailler ...
Il est possible d'ignorer les exceptions, si vous mettez un bloc d'essai / attraper sur chaque ligne de code, mais je ne pense pas que vous voulez vraiment faire cela ...
Dans les cas, disons où vous créez une commande et une erreur dans le processus de création de commande. Ce serait une bonne idée de faire un coup d'œil sur des blocs qui ont une possibilité de casser. De cette façon, vous pouvez toujours obtenir toutes les informations de la commande et votre client n'aura pas à recréer complètement la commande.
Je pense que c'est une bonne amorce sur pourquoi / quand attraper des exceptions: mikehadlow.blogspot.com/2009/08/...
Et simplement parce que c'est dans un essai, le bloc de capture ne signifie pas que vous ignorez le problème. Vous pouvez enregistrer le problème pour pouvoir être examiné et fixé, mais le processus peut continuer. Oui, il y aura des moments où tout devrait s'arrêter à la première étape s'il échoue, mais ce n'est pas toujours le cas.
HONE COURS, vous pouvez enregistrer le problème et prendre les mesures appropriées. Mais, la gestion d'une exception ne signifie pas par défaut que le processus peut continuer. Vous n'êtes pas sûr de pouvoir obtenir les informations dont vous avez besoin. Vous ne savez pas si vous pouvez exécuter l'opération que vous devez, etc ...
Je vois ce que tu veux dire. Tout ce que je dis, c'est que c'est vraiment un cas par cas. Vous ne devriez pas avoir l'essai de prendre des blocs à moins que vous n'ayez vraiment pensé pourquoi il est là et que vous savez que le processus devrait continuer.
@JMEIN: Pensez-vous que vos clients seront heureux quand ils ne reçoivent que la moitié de leur ordre. Ou peut-être qu'ils le feront, si la chose qui est arrivée à la pause était le calcul sous-total.
@erikkalen oh ouais c'est exactement ce que je dis. Vous devriez donner à votre client la moitié de leur commande. Ils ne feront pas remarqueront-ils. Eh bien, je suppose que je dois expliquer. Si vous créez correctement votre processus de commande, vous pouvez toujours avoir toutes les données même si une partie du processus a échoué. Vous pouvez stocker toutes les données dans un fichier à des fins de sauvegarde de l'état afin que même lorsque le processus de commande échoue, vous pouvez corriger la commande manuellement sans que le client doive s'inquiéter à ce sujet. Vous êtes informé de l'erreur afin que vous sachiez qu'il y avait quelque chose de mal avec la commande.
Erikkalen Vous devez également faire attention un peu plus. J'ai dit que cela devrait être utilisé dans le cas par cas. Si cela est quelque chose de très important et que vous ne pouvez évidemment pas continuer alors vous ne faites pas. Vous pouvez gérer l'erreur en conséquence
Vous pouvez toujours faire
try
{
line1
}
catch (Exception ex)
{
}
line2
...
Si vous avez l'intention de ne pas utiliser l'exception, je vous conseillerais de supprimer l'ex de la capture.
Comme suggéré, vous devriez envelopper l'essai autour de la ligne1 dans cet exemple particulier. Toutefois, pour une note future, vous ne devriez vraiment avoir que des conditions dans votre tryan de capture que vous ne voulez que vous souhaitez être complétée s'il n'y a pas d'exception.
S'il y a du code que vous souhaitez toujours être exécuté, même si une exception est levée, même si l'exception n'est pas prise dans le bloc de capture, ou que le bloc de capture rejette ou jette une nouvelle exception, devrait aller dans le bloc "enfin":
Il convient de mentionner que toujours.Runs () pourrait lancer une exception elle-même. Le code «enfin» devrait généralement être «sûr».
try
{
line1
line2
...
}
catch (Exception ex)
{
...
}
finally
{
if(line1ErrorOccured)
{
line2
...
}
}
not given it too much thought though
Vous pouvez isoler chaque ligne dans un bloc de try-catch, cependant, qui viennent de faire des codes à moi. Si vous êtes
Cela fera la même chose que la mienne, à l'exception du code dans le bloc enfin pourrait lancer une exception et vous ne le géreriez pas. Il n'est pas sûr de supposer qu'il ne voudrait pas jeter une exception.
Et je ne recommandais certainement pas de mettre chaque ligne dans un bloc de capture d'essai. Il ne devrait être utilisé que lorsque vous savez qu'il y a une possibilité de rupture de ligne spécifique et que vous savez que le processus devrait continuer si cela le fait.
Je conviens que ce n'est pas sûr de supposer que le code dans un bloc enfin ne casse pas, c'est pourquoi un stressé comme une condition préalable pour le blocage enfin. Il diffère de votre solution dans le sens où il échoue bien et qu'il est plus facile de maintenir / lire au lieu d'avoir à nier que le bloc d'essayer d'essayer le bloc dans le bloc d'essayer, etc. Dans votre exemple, si le type d'exception interne n'est pas capturé, Il va cascader les blocs de capture des parents et éventuellement sauter sur toute une étendue de code.
La prise aurait l'exception afin que cela ne soit pas un problème. Quoi qu'il en soit, votre solution serait une bonne utilisation lorsque vous éliminez des objets pouvant avoir été utilisés pour essayer de prendre des captures. De cette façon, ils seront disposés même si une exception est lancée.
Vous pouvez mettre les autres lignes dans une clause enfin, mais ce serait assez laid, surtout si ceux-ci peuvent également lancer des exceptions ...
Vous devez récupérer de la première exception, puis continuer à la ligne suivante, en emballant chacun dans une déclaration d'essai / attrape.
Enfin, les blocs ne sont pas laids; Ils sont là pour le nettoyage. Supposons que vous ayez une exception lors d'une opération de base de données dans le bloc d'essai. Le bloc enfin est l'endroit où vous devez fermer la connexion et disposer de l'objet de connexion.
C'est pourquoi j'ai dit que c'était moche. Mon point était que supposer que Line2 et après avoir fait le même type de travail que la ligne1, ils ne devraient pas être dans une clause enfin, ou ce serait laid.
Vous pouvez créer une méthode SkiponError comme celle-ci: alors vous pouvez l'appeler comme: note: Je ne suggère pas vraiment que tu fais ça - Au moins pas régulièrement, comme je le trouve plutôt hacky moi-même. Mais il fait quelque chose de montrer certaines des choses fonctionnelles que nous pouvons maintenant faire en C #, yay! Ce que je ferais vraiment, c'est que: refacteur line1 dans une méthode (< em> méthode d'extraction ). Cette nouvelle méthode doit gérer toutes les exceptions prévisibles (si elles peuvent être manipulées) et laissent ainsi l'appelant dans un état connu. Parce que parfois, vous voulez vraiment faire line1 , sauf, c'est peut-être correct si une erreur se produit ...
L'idée n'est pas mauvaise, mais au moins attrape une erreur spécifique ... Sauter toute erreur est très dangereuse et ne devrait pas être faite.
Qu'en est-il de Niching SkiponError?
.. ou fournir une action
C'est essentiellement la même chose que ma réponse, sauf que vous avez eu le temps de poster le code aussi ;-)
Comme d'autres l'ont dit, assurez-vous d'abord que "ignorer" l'exception est ce que vous voulez vraiment faire. Si c'est toujours et que la surcharge syntaxique de tous les captures d'essai est trop élevée, vous pouvez enrouler avec l'Idom exécuté.
Je n'ai pas le temps de dessiner tout le code en ce moment - mais Ce que vous feriez, c'est d'écrire une méthode qui prend un délégué anonyme et l'exécute dans un try-capture (peut-être de connecter toutes les exceptions ou filtrant ceux qui sont «OK»). Appelez cette méthode quelque chose comme TryDo. Vous pouvez alors vous écrire de code comme celui-ci: P>
tryDo( delegate(){ line1; } );
tryDo( delegate(){ line2; } );
S'il est possible de gérer votre exception et de continuer, vous devez localiser vos blocs d'essai / attraper. N'oubliez pas que les exceptions sont exceptionnelles. Si une exception est lancée, quelque chose aurait dû passer mal. Vous devriez essayer d'empêcher les exceptions en premier lieu.
Vous aurez besoin de pertinents réifiables pour le faire. Le CLR et C # ne supporte pas cela et ne le feront probablement jamais. : (
Êtes-vous portant le code VB6 qui (comme la plupart) abus
sur erreur de reprend Suivant ?Je comprends que les bowvotes sont parce que ce serait une terrible pratique terrible, mais je pense que cela devrait être avancé. Ce n'est pas le seul développeur qui a été soulevé dans la tradition du VB6 "sur la résolution des erreurs suivante" et que cette information a vraiment besoin d'obtenir à tous. Je suppose que je vis un uppote pour cette question en tant que uppote pour la réponse - promouvoir la cure plutôt que la maladie.
@Op, qu'est-ce que vous essayez de faire est d'ignorer, sans éviter.