web-dev-qa-db-fra.com

Quoi de mieux: int.TryParse ou essayez {int.Parse ()} catch

Je sais .. Je sais ... La performance n'est pas la principale préoccupation ici, mais juste pour la curiosité, quoi de mieux?

bool parsed = int.TryParse(string, out num);
if (parsed)
...

OR

try {
    int.Parse(string);
}
catch () {
    do something...
}
c#.netparsingtype-conversiontryparse
59
renanleandrof

Mieux est très subjectif. Par exemple, je préfère personnellement int.TryParse, car je ne me soucie pas le plus souvent pourquoi l'analyse échoue, si elle échoue. Pourtant, int.Parse peut (selon la documentation ) lever trois exceptions différentes:

  • l'entrée est nulle
  • l'entrée n'est pas dans un format valide
  • l'entrée contient un nombre qui provoque un débordement

Si vous vous demandez pourquoi cela échoue, alors int.Parse est clairement le meilleur choix.

Comme toujours, le contexte est roi.

82
Fredrik Mörk

Est-ce exceptionnel que la conversion échoue parfois, ou est-ce attendu et normal que la conversion échouera parfois? Si le premier, utilisez un exception. Si ce dernier, éviter les exceptions. Les exceptions sont appelées "exceptions" pour une raison; vous ne devez les utiliser que pour gérer les circonstances exceptionnelles.

39
Eric Lippert

Si l'on s'attend en effet à ce que la conversion échoue parfois, j'aime utiliser int.TryParse et bien sur une seule ligne avec opérateur conditionnel (ternaire) , comme ceci:

int myInt = int.TryParse(myString, out myInt) ? myInt : 0;

Dans ce cas, zéro sera utilisé comme valeur par défaut si la méthode TryParse échoue.

Également très utile pour les types nullables, qui écraseront toute valeur par défaut avec null si la conversion échoue.

19
greg84

La première. Le second est considéré codage par exception.

10
George Johnston

Personnellement, je préfère:

if (int.TryParse(string, out num))
{
   ...
}
8
Paddy

La première! Vous ne devez pas coder par exception.

vous pouvez le raccourcir

if (int.TryParse(string, out num))

4
Mr Shoubs

D'abord, de loin. Comme l'a dit George, le deuxième est le codage par exception et a des impacts majeurs sur les performances. Et la performance devrait toujours être une préoccupation.

3
Madeleine

Attraper une exception a plus de frais généraux, je vais donc essayer TryParse.

De plus, la méthode TryParse ne lève pas d'exception si la conversion échoue. Il élimine la nécessité d'utiliser la gestion des exceptions pour tester une exception FormatException dans le cas où s n'est pas valide et ne peut pas être analysé avec succès.

Cette dernière partie copiée de ici

2
tzup

Il faut également garder à l'esprit que les exceptions sont enregistrées (facultativement) dans la fenêtre de débogage/sortie de Visual Studio. Même lorsque la surcharge de performances des exceptions peut être insignifiante, l'écriture d'une ligne de texte pour chaque exception lors du débogage peut ralentir les choses. Des exceptions plus notables pourraient également se noyer parmi tout le bruit des opérations d'analyse de nombres entiers ayant échoué.

1
Quppa