Затраты на производительность блока try / catch [дубликат]

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

Создание исключений и их обработка обходятся дорого. Попробовать .. поймать .. наконец неплохо.

Теперь с учетом сказанного: если вы собираетесь перехватить исключение, у вас должен быть план того, что вы собираетесь с ним делать. Нет смысла ловить, если вы просто собираетесь перебросить, и в большинстве случаев вы мало что можете сделать, если получите исключение.

Мне сказали, что добавление попытки блок catch добавляет большую производительность стоит порядка 1000 раз медленнее чем без, в примере для петля на миллион. Это правда?

Использование try catch увеличивает производительность, но это не главное снижение производительности.

Разве не лучше использовать блок try catch? как можно больше?

Нет, лучше всего использовать блок try catch, когда это имеет смысл.

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

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

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

Если вы используете функции, которые могут сбивать с толку, вы делаете выбор. Ошибка критическая => сбой приложения. Является ли ошибка некритической и вероятной => поймать ее (и, возможно, зарегистрировать).

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

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

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

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

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

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

Зачем гадать о затратах на производительность, если вы можете протестировать их и посмотреть, имеет ли это значение?