Что лучше: int.TryParse или try {int.Parse()} catch

Я знаю.. Я знаю... Производительность здесь не самая главная проблема, но только для любопытства, что лучше?

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

ИЛИ

try {
    int.Parse(string);
}
catch () {
    do something...
}

Ответ 1

Лучше очень субъективно. Например, я лично предпочитаю int.TryParse, так как мне часто все равно, почему синтаксический анализ не удается, если он терпит неудачу. Тем не менее, int.Parse может (согласно документации) выбросить три разных исключения:

ввод равен null
вход не находится в допустимом формате
вход содержит число, которое передает переполнение

Если вам небезразлично, почему это не удается, тогда int.Parse, безусловно, лучший выбор.

Как всегда, контекст является королем.

Ответ 2

Является ли исключительным для того, чтобы преобразование иногда терпело неудачу, или это ожидалось и нормальное, что преобразование иногда терпит неудачу? Если первое, используйте исключение. Если последние, избегайте исключений. Исключения называются "исключениями" по какой-либо причине; вы должны использовать их только для устранения особых обстоятельств.

Ответ 3

Если действительно ожидается, что преобразование будет иногда терпеть неудачу, мне нравится использовать int.TryParse и так аккуратно в одной строке с условным (тройным) оператором, например:

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

В этом случае нуль будет использоваться как значение по умолчанию, если метод TryParse терпит неудачу.

Также очень полезно для типов с нулевым значением, которые будут перезаписывать любое значение по умолчанию с помощью null, если преобразование завершается неудачно.

Ответ 4

Первый. Второй считается кодировкой по исключению.

Ответ 5

Лично я бы предпочел:

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

Ответ 6

Первый! Вы не должны кодировать по исключению.

вы можете сократить его до

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

Ответ 7

Во-первых, безусловно. Как сказал Джордж, во-вторых, кодирование по исключению и имеет серьезные последствия для производительности. И производительность должна быть проблемой, всегда.

Ответ 8

Устранение исключения имеет больше накладных расходов, поэтому я перейду к TryParse.

Кроме того, метод TryParse не генерирует исключение, если преобразование завершается с ошибкой. Это устраняет необходимость использования обработки исключений для проверки для FormatException в случае, если s недействителен и не может быть успешно проанализирован.

Эта последняя часть скопирована с здесь

Ответ 9

Что-то еще, о чем нужно помнить, заключается в том, что исключения регистрируются (необязательно) в окне отладки/вывода Visual Studio. Даже если издержки на производительность исключений могут быть незначительными, написание строки текста для каждого исключения, когда отладка может замедлить работу. Более примечательные исключения могут быть утоплены среди всех шумов неудачных целых операций синтаксического анализа.