Это очевидный вопрос:
Почему эта штука попадает в мою попытку поймать, даже если нет ничего плохого?
Почему это появляется в моем журнале, сотни раз?
Я знаю, это новый вопрос, но если этот сайт получит поисковый рейтинг и привлечет новичков, мы должны спросить их
Вероятно, это происходит от вызова Response.Redirect. Проверьте эту ссылку для объяснения:
http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx
(В большинстве случаев вызов Response.Redirect (url, false) решает проблему)
Наиболее распространенной причиной исключения ThreadAbortException является вызов Response.End, Response.Redirect или Server.Transfer . Microsoft опубликовала некоторые предлагаемые функции, которые следует использовать вместо этих функций.
Как уже говорили другие, это происходит, когда вы вызываете Response.End () (что происходит, когда вы вызываете Response.Redirect, не передавая false в качестве второго параметра). Это работает как задумано; обычно, если вы вызываете Response.Redirect, вы хотите, чтобы перенаправление происходило немедленно. Смотрите это для получения дополнительной информации:
Зная, что есть (по крайней мере) три 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?
Люк
Причина, по которой Response.Redirect выдаст это исключение, заключается в том, что asp.net внутренне реализует этот API с помощью Thread.Abort (). Когда вызывается этот метод, генерируется специальная исключительная ситуация ThreadAbortException. Это исключение не будет поглощено никаким блоком перехвата. Он будет переброшен в конце каждого блока улова.