Как trycatch повредить память / процессор?

Question

, поэтому я заинтересован в стороне c #, но я помечаю тегом c ++, поскольку концепция существует там, и я не нахожусь над ключевым словом 'finally'.Так или иначе - есть ли онлайн-тесты о том, как try-catch будет замедляться или будет использовать больше памяти, чем простой if-else или другой код?Например, сейчас я пишу код и использую Streamwriter, который показывает 7 возможных исключений, когда вы наводите на него курсор мыши ... поэтому кто-нибудь будет утверждать, что это будет быстрее, если я напишу что-то вроде:

//////////////
if(path is not too long)
{ if(file exists)
{ if(nothing else uses the file)
{ if(user is authorized)
}}}
////////////

У вас есть 7 условий, и вы можете использовать вместо этого просто try-catch - не говоря уже о том, что эти условия нельзя упростить до одного оператора if.

10x!

Answer 1

try / catch имеет небольшое снижение производительности, если возникает исключение, но по сравнению с доступом к файлам о стоимости не стоит беспокоиться.

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

См

• http://blogs.msdn.com/b/jaredpar/archive/2009/12/10/the-file-system-is-unpredictable.aspx
• http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx
• как можно легко проверить, запрещен ли доступ к файлу в .NET?

Все эти примеры используют файлы, но здесь есть общий принцип для общих ресурсов.

Answer 2

Любые различия в производительности - не главное.

Проверка того, что файл существует в какой-то момент перед открытием, не гарантирует, что другой поток или процесс не удалили или не заблокировали файл; Вы знаете только в момент попытки открыть его независимо от того, добились ли вы успеха. Следовательно, вызовы ОС часто возвращают коды успеха или ошибок или возвращают известное значение, указывающее на недопустимый дескриптор файла.

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

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

Answer 3

Для действительно блестящего дискурса об обработке исключений и его последствиях (будь то стоимость, стабильность системы и т. Д.) Я рекомендую прочитать Глава 20 великой работы "CLR via C #" Джеффри Рихтер . Он определенно ответит на большинство ваших вопросов и поможет понять, как .NET Framework обрабатывает исключения изнутри, и как использовать Performance Counter в качестве средства для оценки воздействия исключений, которые выдает ваш код.

Использование сторожевых выражений (как вы упоминаете в своем вопросе) не является альтернативой обработке исключений, это два дополнительных понятия. Защитное условие, например if(file exists), может вызвать короткое замыкание остальных условий и повысить производительность, поскольку вашему коду может не потребоваться тестирование следующих условий, т. Е. if(user is authorized) может быть ресурсоемким или занимать много времени.