Допустимо ли иметь необработанные исключения в веб-приложениях ASP.NET?

Question

В настоящее время я работаю со сторонним поставщиком, который предоставил веб-приложение 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 довольно агрессивны, генерируя около 5000 обращений в день).Хотя я согласен с тем, что регулирование GoogleBot сработает, мне кажется, что это отговорка.Я всегда считал необработанные исключения ошибками.Разве веб-приложение не должно обрабатывать эти ошибки? когда-либо допустимо, чтобы HTTP / 500 происходил?Что думают веб-разработчики?

Answer 1

Здесь действительно несколько вопросов : если веб-сайт отображает исключения (Нет), если веб-сайт отображает что-то более дружественное для пользователей (Да), если веб-сайт возвращает ошибку 500 роботу Googlebot, когда это не может продолжаться (вероятно), если вы попросите робота Google замедлиться (да), если вы будете отправлять 500 сообщений об исключениях в день без регулирования или суммирования (вероятно, нет).

Подробнее: -

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

Вы никогда не должны показывать Исключение пользователям, вы всегда должны ловить его и отображать дружественную страницу ошибок, НО вы должны быть осторожны, чтобы сохранить HTTP-код при отображении этой страницы (например, 404 или 500), так как если вы возвращаете страница с кодом = 200, то эта страница с ошибкой найдет свое место в индексах поисковой системы.

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

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

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

Answer 2

Веб-разработчик не желает обрабатывать исключение в веб-сервисе ?

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

Итак, у вас есть три варианта

1. Дросселировать Google каким-то образом;
2. Продлить пособие по веб-сервису; или
3. Оплата за изменение сайта.

Answer 6

Веб-приложение обрабатывает ошибки по электронной почте.

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

Похоже, вам нужен более изящный способ убедиться, что сайт масштабируется без стороннего сервиса. Мне не ясно, какой поставщик (разработчик ASP.NET или сторонний сервис) должен работать над этим, но это больше проблема управления проектами.