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





Вероятно, это происходит из-за вызова Response.Redirect. Проверьте эту ссылку для объяснения:
http://dotnet.org.za/armand/archive/2004/11/16/7088.aspx
(В большинстве случаев вызов Response.Redirect (url, false) устраняет проблему)
Ответ Эрика правильный, но вы должны знать, что передача параметра false означает, что текущий поток не прерван, то есть будет запущен код после Response.Redirect.
Наиболее частой причиной исключения 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 сканирует наш сайт более агрессивно в поисках изображений.
Первым делом нужно было выяснить, почему только робот Googlebot может вызвать эту проблему. Ни один другой клиент не запускал код, использующий Response.Redirect или что-то еще.
Итак, в обработчике HttpApplication.Error я добавил код для регистрации дополнительных подробных выходных данных со всеми заголовками, и большая часть данных в HttpResponse и HttpContext была отправлена в журнал.
Это позволило мне увидеть, что проблема заключалась в том, что робот Googlebot использует строку пользовательского агента iPhone, и, вооружившись этим, я смог выполнить поиск в базе кода для «iPhone» и придумал:
private void CheckIPhoneAccess() { ... }
И для этого используется перенаправление.
Что с этим делать?
Что ж, для этой устаревшей кодовой базы не стоит ретропатчить все вызовы Response.Redirect, поэтому я собираюсь снизить уровень ведения журнала для ThreadAbortException для приложения.
Я изменю поведение мобильного поискового робота Googlebot, так что нет будет приводить к «лжи» о том, что наш сайт обслуживает для мобильных устройств, поскольку он перенаправляется только при первом обращении, впоследствии он считывает cookie и показывает изображение. Робот Googlebot не кэширует этот файл cookie.
Это не идеально, но сайт нужно перестроить. вероятно, другой командой, использующей Scala или что-то в этом роде, так что с практической точки зрения я думаю, что это хороший выбор. Я добавлю комментарии и, возможно, вернусь к проблеме позже, создав расширение Response.SafeRedirect, которое инкапсулирует этот совет:
Почему Response.Redirect вызывает исключение System.Threading.ThreadAbortException?
Люк
Необходимо добавить, файл cookie HaveSeenIPhonePromo никогда не устанавливался, поэтому робот Googlebot-Mobile продолжал перенаправлять. Это была основная причина.
Причина, по которой Response.Redirect выдаст это исключение, заключается в том, что asp.net внутренне реализует этот API с помощью Thread.Abort (). Когда этот метод вызывается, генерируется специальное исключение ThreadAbortException, которое не будет поглощено никаким блоком catch. Он будет повторно брошен в конце каждого блока catch.
Обратите внимание, что ссылка выше не работает