C #: должны быть пойманы все исключения - PullRequest
5 голосов
/ 22 марта 2011

Должны ли все исключения быть перехвачены в программе на C # или есть некоторые исключения (например, переполнение стека, нехватка памяти и т. Д.), Которые следует разрешить аварийному завершению работы программы, поскольку нет способа восстановить их?

Ответы [ 6 ]

7 голосов
/ 22 марта 2011

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

3 голосов
/ 22 марта 2011

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

См. Этот вопрос о перехвате OutOfMemoryException (обычно вы можете восстановить его), и этот пример о перехвате StackOverflowException (как правило, невозможно).

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

Невозможно (полностью) подготовиться к неожиданному.

1 голос
/ 22 марта 2011

MSDN статья на тему:

http://msdn.microsoft.com/en-us/library/ms229005.aspx

Основные моменты:

Избегайте обработки ошибок, перехватывая неспецифические исключения, такие как System.Exception, System.SystemException и т. Д. В коде приложения.Есть случаи, когда обработка ошибок в приложениях является приемлемой, но такие случаи редки.

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

Вы должны ловить только те исключения, которые вы можете восстановить....

Do предпочитает использовать пустой бросок (throw;) при перехвате и повторном броске исключения.Это лучший способ сохранить стек вызовов исключений.

Журнал MSDN по обработке исключений изменений в .NET 4.0 - «Все еще неправильно использовать Catch (исключение e)» - http://msdn.microsoft.com/en-us/magazine/dd419661.aspx#id0070057

1 голос
/ 22 марта 2011

Из POV разработки коммерческих приложений должны быть перехвачены все исключения, и НИКОГДА не должно быть разрешено аварийно завершить работу программы. Потому что в настоящее время пользователи компьютеров могут различать сообщение об ошибке и диалоговое окно сбоя приложения.

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

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

Хотя конечный результат такой же, но понятное сообщение об ошибке создает гораздо лучшее впечатление, чем диалоговое окно, генерируемое ОС.

1 голос
/ 22 марта 2011

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

0 голосов
/ 22 марта 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...