2015-08-07 2 views
0

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

catch (System.Net.Sockets.SocketException netEx) 
      { 

      } 

catch (Exception ex) 
      { 

      } 
+1

Производительность напрямую связана с сложностью алгоритма и связана с тем, сколько кода должно быть выполнено. Имея два «уловных» высказывания, просто говоря, это похоже на наличие двух IF, а не одного оператора IF. Для этого случая необходимо создать больше MSIL для обработки двух возможных ситуаций, поэтому будет больше кода JIT-ed. Но я бы не стал отказываться от особых ошибок! Очень важно уловить определенные исключения, потому что вы можете реагировать на большее количество acuratelly и может восстанавливаться легче. –

+0

Неверный вопрос на столько уровней. – Paparazzi

+0

Как это неправильный вопрос? Я не прошу помощи по дизайну. Я не прошу лучших практик. Мне любопытно, есть ли разница в производительности между более зернистым исключением исключений и более общим исключением. –

ответ

2

Я бы не подумал об этом с точки зрения производительности.

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

Когда вы поймаете Exception, ваш обработчик исключений будет проглатывать любое исключение, даже если вы не готовы к его устранению. Представьте, что заброшено ArgumentNullException. Блок catch будет проглотить его и вызвать путаницу.

Если все, что вы готовы обработать, это SocketException, а затем просто поймайте это. Если он менее эффективен, пусть будет так. Код Корректность не то, чтобы принести в жертву для такого крохотного прироста производительности *

* или нет прироста производительности на всех - я почти наверняка есть нулевой время выполнения Подразумевается производительность на всех. Я сделал тест на своем компьютере, и производительность более или менее одинакова. Это был не всесторонний тест, но этого было достаточно, чтобы подтвердить мой инстинкт. Вы можете запустить свой собственный бенчмарк, используя метод, аналогичный this one

Смежные вопросы