Действительно ли приемлемо иметь необработанные исключения в веб-приложениях ASP.NET?
Я работаю со сторонним поставщиком в данный момент, который предоставил веб-приложение ASP.NET. Веб-приложение генерирует приблизительно 200 необработанных исключений в день, которые заканчиваются как электронные письма в моем ящике входящих сообщений. После расследования оказывается, что большинство этих ошибок инициировано поисковым роботом GoogleBot, индексирующим сайт и инициировавшим доступ к другому стороннему веб-сервису, который является ограничением уровня запросы. Когда предел запроса превышен, сторонний веб-сервис отказывается от запроса, это приводит к необработанному исключению в веб-сервере и коде состояния HTTP/500. Исключение похоже на это:
Exception: Exception of type 'System.Web.HttpUnhandledException' was thrown., Stack Trace: at System.Web.UI.Page.HandleError(Exception e) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) at System.Web.UI.Page.ProcessRequest() at System.Web.UI.Page.ProcessRequest(HttpContext context) at ASP.views_products_detail_aspx.ProcessRequest(HttpContext context) at System.Web.Mvc.ViewPage.RenderView(ViewContext viewContext) at System.Web.Mvc.ViewResultBase.ExecuteResult(ControllerContext context) at System.Web.Mvc.ControllerActionInvoker.c__DisplayClass11.b__e() at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultFilter(IResultFilter filter, ResultExecutingContext preContext, Func`1 continuation) at System.Web.Mvc.ControllerActionInvoker.InvokeActionResultWithFilters(ControllerContext controllerContext, IList`1 filters, ActionResult actionResult) at System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName)
Разработчик веб-приложения кажется не желающим обработать эти ошибки по причинам, которые я действительно не понимаю. Их подход должен отрегулировать GoogleBot, пока ошибки не прекращают происходить (индексы Google вполне настойчиво, генерируя приблизительно 5 000 хитов в день). В то время как я признаю, что регулировка GoogleBot работала бы, это походит на отговорку мне. Я всегда полагал, что необработанные исключения ошибки. Разве веб-приложение не должно обрабатывать эти ошибки? Когда-либо приемлемо позволить HTTP/500 происходить? Что там думают веб-разработчики?
6 ответов
Здесь на самом деле несколько вопросов: должен ли веб-сайт отображать исключения (Нет), должен ли веб-сайт отображать что-то более дружелюбное для пользователей (Да), должен ли веб-сайт возвращать Googlebot ошибку 500, когда он не может продолжить работу (Возможно), должны ли вы попросить Googlebot замедлиться (Да), должны ли вы отправлять 500 писем с исключениями в день без дросселирования или суммирования (Возможно, нет).
Более подробно:-
Используя google.com/webmasters, вы можете запросить, чтобы Google индексировал ваш сайт менее агрессивно.
Вы никогда не должны показывать исключение пользователям, вы всегда должны поймать его и показать дружественную страницу ошибки, но вы должны быть осторожны, чтобы сохранить код HTTP при отображении этой страницы (например, 404 или 500), так как если вы вернете страницу с кодом = 200, то эта страница ошибки попадет в индексы поисковых систем.
Любой обработчик ошибок должен ограничивать частоту отправки сообщений электронной почты при возникновении ошибок.
Хорошо написанный обработчик ошибок должен также позволять подавлять ошибки, о которых вы знаете, что они возникнут - например, некоторые поисковые системы настаивают на запросе несуществующих страниц.
Если Google может ввести вас в ситуацию ограничения скорости, то высокий трафик от пользователей может сделать то же самое, так что в целом похоже, что вам нужно какое-то решение для кэширования и здесь.
Веб-разработчик не желает обрабатывать исключение в веб-службе?
Это довольно пугающе, поскольку существует множество причин, по которым веб-служба может вызвать исключение. Вместо того чтобы просить исправить проблему с GoogleBot, попробуйте попросить разработчика разрешить приложению плавно деградировать, если веб-служба недоступна.
Нет, это неприемлемо. Веб-приложение должно, по крайней мере, ловить исключения в global.asax.cs и делать с ними что-то разумное.
IMO это на самом деле довольно приемлемо. Проблема в том, что вы достигли точки насыщения сервиса. Есть два способа справиться с этим: либо потратить деньги и время, необходимые для повышения точки насыщения и получить больше услуг или потратить время и деньги, чтобы сделать себя не зависимым от этих услуг.
Edit: Есть и третий вариант, который заключается в том, чтобы последовать примеру NY Times, рассматривающей Google как вора ваших услуг, и просто запретить его. Конечно, на самом деле это все равно, что засунуть голову в песок, но это вариант.
Веб-приложение обрабатывает ошибки, отправляя вам электронное письмо.
Что меня интересует, что если настоящий посетитель сайта столкнется с этой ошибкой, как бы вы хотели ее обработать? Я полагаю, вы захотите получить письмо по электронной почте, если бы настоящий посетитель столкнулся с этой ошибкой. Может быть, некоторые из этих ошибок исходят от реальных посетителей, потому что Google израсходовал свою квоту?
Похоже, вам нужен более изящный способ в целом обеспечить масштабирование сайта без сторонней службы. Мне не ясно, какой поставщик (разработчик ASP.NET или сторонняя служба) должен работать над этим, но это скорее проблема управления проектом.
Произошла ситуация, не зависящая от поставщика. Поставщик зарегистрировал ошибку и отправил вам уведомление. Поставщик не может контролировать ограничение на веб-службу или количество посетителей вашего сайта. Вы контролируете и то, и другое.
Если в спецификации не указано, что электронные письма следует каким-то образом ограничивать, позиция поставщиков является обоснованной. Вы хотите, чтобы работа была сделана, вы платите за нее.
Итак, у вас есть три варианта:
- Каким-то образом ограничить доступ к Google;
- Увеличить лимит веб-сервисов; или
- Оплатить изменение веб-сайта.