Как лучше всего обрабатывать исключения и как с ними обращаться в asp.net

Question

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

Я создаю N-Layered приложение. поэтому я думаю, что DAL когда-нибудь сгенерирует некоторые ошибки для обработки ... и я только что узнал о классе SqlException, что за дело с этим классом? Однажды я видел код, который обрабатывает SqlException, затем он обрабатывает Exception!

После изучения практики и того, где я собираюсь их обработать, я планирую создать метод для подключения к базе данных и регистрации ошибок в базе данных, чтобы я мог это исправить, но все же я не знаю, что информацию, которую я должен собрать, чтобы я мог определить всю ситуацию!

---

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

"Не просто явно поймать исключения "

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

EDIT

Что насчет Page_Error события и Application_Error .. Я видел, что они являются хорошей практикой для обработки ошибок

Answer 1

Обработка исключений - это большое дело, и не так просто разработать хорошую стратегию для этого.

Прежде всего, некоторые общие правила:

• Исключения возникают при выполнениикод совершенно не способен продолжить работу, поэтому, возможно, он пытался обработать некоторые внутренние исключения, но в итоге потерпел неудачу.Подумайте о соединении TCP: если приходит поврежденный пакет, это исключение, но протокол TCP может справиться с этим.Если слишком много повреждено, генерируется исключение ввода-вывода или сокета
• Исключения не всегда могут быть обработаны .Почти во всех случаях, когда вы получаете исключение из нижележащих слоев, вы не можете выполнить корректирующий код.Если ваше приложение зависит от БД и находится в автономном режиме, при получении исключения об этом вы можете отобразить только сообщение об ошибке
• Исключения могут быть неожиданными и могут выявить недостатки проектирования или реализации.Например, недостатком реализации может быть ситуация, в которой у вас есть избыточная БД, но когда вы не можете подключиться к зеркалу, вы не пытаетесь со вторым

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

Прежде всего

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

Не начинайте писать try-catch (Exception), но предпочитайте конкретные исключения.Если вам нужно разобрать строки по числам и т. Д., Тогда ожидайте FormatException, если вам нужно привести от Object к вашему типу, ожидайте InvalidCastException

Когда вы пишете слои нижнего уровня

не стесняйтесь бросать исключения!Не делай так, как делают многие, т.е.return null или используйте (как ANSI C) логическое возвращаемое значение и опорные параметры.Для этого есть исключения.Если вы можете обработать исключение (т. Е. Вы не нашли локальный файл, но знаете, что у вас есть удаленная резервная копия, поэтому обработайте FileNotFoundException, вызвав удаленное зеркало, но если вы все еще не можете подключиться, то, в конечном счете, сбросьте), тогдасделать это и попытаться возобновить вычисления, но если вы не можете, то бросьте.И не забудьте выбросить внутреннее исключение, если оно есть, потому что это полезно для входа в верхний слой.

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

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

Когда вы регистрируете

, не забудьте придать сообщениям достаточную строгость.Если через код вы обнаружите, что ваша БД отключена, это не является неожиданным исключением.Тем не менее, регистрируйте его как ошибку, но не беспокойтесь об ошибках кода при изучении журналов.Вместо этого, если вы поймете исключение, которое ваш код не может распознать (NullReferenceException - классический пример), тогда ведите журнал с наибольшей серьезностью, т.е.фатальный, чтобы дать ему максимальный приоритет!

Хорошая стратегия для ASP.NET

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

Вы также не должны злоупотреблять блоками try-catch (Exception), потому что если вы не поймаете исключение, вы можете 'Чтобы справиться с catch, вам придется обработать его с помощью OnError.

Когда вы запускаете такой метод, не думайте сразу о Server.RemoveError().Вы можете предпочесть статическую HTML-страницу для ошибки HTTP 500 (которая запускается, когда необработанное исключение переходит в среду выполнения ASP.NET), которая отображает сообщение вежливости пользователю.

Кратко

1. Не стесняйтесь throw в нижележащих слоях, если происходит что-то странное
2. Как сказано в вашем совете, не обрабатывайте исключения, которые вы не можете обработать (если вы поймали исключение, которое не можете обработать, сбросьте его)
3. LOG !!!!!!!!!!!!!!!!!
4. Не разглашайте подробности исключений конечным пользователям на общедоступном веб-сайте, никогда !! По умолчанию ASP.NET предотвращает это, но вы все равно можете использовать OnError для печати трассировки стека
5. Используйте OnError или Application_Error в качестве единой центральной точки для обработки всех непредвиденных исключений
6. Периодически проверяйте журналы на наличие сообщений об ошибках / фатальных ошибках, чтобы найти проблемы с вашим кодом, а затем подумайте о том, чтобы поддерживать / отлаживать / исправлять его

Answer 2

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

Я думаю, что оно включает в себя:

Где - Все места, где, по вашему мнению, может возникнуть исключение или которые требуют дополнительного мониторинга, например, вызовы БД, внешние сервисные вызовы, использование массивов, Парсинг пользовательского ввода, приведение типов и т. Д. ...

Как - Все высокоуровневые слои должны выдавать исключение, и оно должно быть захвачено в точке входа и обработано для пониманияпервопричина.Обычно вы делаете это в Application_Error (), где перехватываете исключение и регистрируете его для устранения неполадок.Как вы регистрируете исключение, зависит от вас.Файл журнала или журнал, управляемый БД, - это опция, основанная на ваших требованиях и доступных ресурсах.

Answer 3

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

---

Что касается ваших конкретных вопросов,

Я только что узнал о классе SqlException, что за дело с этим классом?Однажды я видел код, который обрабатывает SqlException, затем он обрабатывает Exception!

Рекомендуется обрабатывать конкретное исключение, которое, как вы считаете, может возникнуть, если вы не уверены, какой тип этого исключения вы можете просто «Exception»', если вы хотите, чтобы что-то конкретное происходило с' SQLException ', а что-то еще происходило с' Exception ', тогда, конечно, нет ничего плохого в написании кода, который обрабатывает оба.

---

«Не просто явно перехватывать исключения»

Я полагаю, что это относится к коду, подобному этому

try 
{
   int i = 1/0;
} 
catch(Exception e)
{
  //do nothing
}

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

Answer 4

Посмотрите на Элму.Это логгер для asp.net.Отображает все ошибки на удобной сводной странице.

http://code.google.com/p/elmah/

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

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

Ошибка подключения SQL лучше всего обрабатывается в DAL ... и т. Д.

Answer 5

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

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