Что лучше/быстрее? Попробовать или избежать исключения?

Ответ 1

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

В общем, не используйте исключения для управления потоком. Они фактически являются нелокальными goto, что делает программы более трудными для чтения и наблюдения. Таким образом, они должны быть зарезервированы для исключительных ситуаций. Если вы можете избежать использования блока try-catch для управления потоком, не делайте этого. Ваши программы будут более читабельными и поддерживаемыми.

"Правильный" способ справиться с этой ситуацией -

var list = someMethod();
if(list == null || list.Length == 0) {
    // handle something bad
}
string a = list[0];
if(a != null) {
    // go
}

Вы можете избежать проверки того, что list не является нулевым и не пустым, если есть контракт (Contract.Ensures), который гарантирует, что возвращаемое значение из someMethod не является нулевым, а не пустым.

Правда, эти исключения являются локально дорогостоящими. Независимо от того, повлияют ли они на производительность вашей программы (т.е. Узкое место), это еще один вопрос. Но правильно используемые, исключения, как правило, не являются узким местом (кто заботится о производительности, когда ваше приложение терпит крах?)

Ответ 2

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

Исключения не должны использоваться для нормального потока программы.

Ответ 3

Это зависит. Я почти всегда стараюсь избегать исключения, если это не является чрезмерно дорогостоящим.

Ответ 4

конечно, избегайте исключения, попытка catch ведет к снижению производительности.

Ответ 5

ВСЕГДА ВСЕГДА ВСЕГДА избегайте исключения, если можете.

Исключения должны быть исключительными.

Если вы можете предсказать это, предохраняйте его.

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

Это также быстрее, чтобы не попасть в блоки catch.

Ответ 6

Чисто из нескольких инструкций/точки зрения производительности в течение значительного времени выполнения N, избегая дороже, потому что вы каждый раз проверяете длину каждого входа. За исключением того, что ветвь catch выполняется только в этом случае.

Ответ 7

Бросание исключений - дорогостоящая задача, поэтому я всегда стараюсь проверять, а не ловить.

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

Если код документирован с подробными сведениями о том, какие условия будут исключены, вы сможете адаптировать свой код вызова. Конечно, вы не можете обрабатывать каждый сценарий (возможно, ошибки времени выполнения на более низком уровне), поэтому ваш код должен только попробовать и обрабатывать исключения, где он может реагировать и, возможно, продолжать.

Ответ 8

Исключения должны использоваться только для исключительных условий (если нет альтернативы), поэтому вы должны использовать try/catch, когда есть что-то необычное, с которым вам все еще нужно иметь дело (всплывающее сообщение об ошибке).

Наличие try/catch также сигнализирует программисту о том, что может произойти какая-то внешняя ошибка, и с этим нужно иметь дело. В вашем примере list, являющийся нулевым, является просто нормальной частью потока выполнения программы/управления, поэтому нет ничего исключительного в этом.

Кроме того, пустая уловка, как правило, является плохой вещью, чтобы иметь в любом случае (хотя есть ситуации, когда это необходимо). В любом случае, это обязательно должно быть комментарий, чтобы объяснить, почему вы ничего не делаете об исключениях.

Там полезный пост в блоге о неприятном исключении, которое вы можете найти полезным