Почему мое приложение asp.net вызывает исключение ThreadAbortException?

Question

самоочевидный вопрос.

Почему эта штука всплывает в моем улове, даже если все в порядке?

Почему это появляется в моем журнале, сотни раз?

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

Answer 1

Вероятно, это происходит от вызова Response.Redirect. Проверьте эту ссылку для объяснения:

http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx

(В большинстве случаев вызов Response.Redirect (url, false) решает проблему)

Answer 2

Наиболее распространенной причиной исключения ThreadAbortException является вызов Response.End, Response.Redirect или Server.Transfer . Microsoft опубликовала некоторые предлагаемые функции, которые следует использовать вместо этих функций.

Answer 3

Как уже говорили другие, это происходит, когда вы вызываете Response.End () (что происходит, когда вы вызываете Response.Redirect без передачи false в качестве второго параметра). Это работает как задумано; обычно, если вы вызываете Response.Redirect, вы хотите, чтобы перенаправление происходило немедленно. См. Это для получения дополнительной информации:

Response.Redirect и исключение ThreadAbortException

Answer 4

Причина, по которой Response.Redirect выдаст это исключение, заключается в том, что asp.net внутренне реализует этот API с помощью Thread.Abort (). Когда вызывается этот метод, генерируется специальная исключительная ситуация ThreadAbortException. Это исключение не будет поглощено никаким блоком перехвата. Он будет переброшен в конце каждого блока улова.

Answer 5

Зная, что есть (по крайней мере) три API-интерфейса, которые внутренне используют Thread.Abort, я хотел бы ответить более практично, как решить, что с этим делать.

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

В журналах log4net показывалось, что заголовок X-Forwarded-For (мы за NLB) был IP-адресом Googlebot, 66.249.78.x, что укрепило мою теорию об изменении карты сайта, которая привела к тому, что Google сканировал наш сайт более агрессивно, ища изображения.

Первым делом выяснилось, почему только робот Google мог вызвать эту проблему. Ни один другой клиент не запускал какой-либо путь кода, использующий Response.Redirect, или любой другой.

Итак, в обработчике HttpApplication.Error я добавил некоторый код для регистрации дополнительных подробных выходных данных со всеми заголовками, и большая часть данных в HttpResponse и HttpContext выбрасывалась в журнал.

Это позволило мне увидеть, что проблема заключалась в том, что робот Googlebot использует строку агента пользователя iPhone и, вооружившись этим, я смог найти в кодовой базе "iPhone" и найти:

private void CheckIPhoneAccess() { ... }

И это использует Redirect.

Что с этим делать?

Ну, для этой устаревшей кодовой базы не стоит ретро-патчировать все вызовы Response.Redirect, поэтому я собираюсь понизить уровень ведения журнала для ThreadAbortException для приложения.

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

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

Почему Response.Redirect вызывает исключение System.Threading.ThreadAbortException?

Люк