Когда вызывается ASP.NET System.Web.HttpResponse.End (), текущий поток прерывается?
когда вызывается System.Web.HttpResponse.End (), запускается System.Thread.Abort, что, как я предполагаю, является (или вызывает) исключение? У меня есть записи, и они перечислены в файле журнала ...
Первый шанс
exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
12/14/2008 01:09:31::
Error in Path :/authenticate
Raw Url :/authenticate
Message :Thread was being aborted.
Source :mscorlib
Stack Trace : at System.Threading.Thread.AbortInternal()
at System.Threading.Thread.Abort(Object stateInfo)
at System.Web.HttpResponse.End()
at DotNetOpenId.Response.Send()
at DotNetOpenId.RelyingParty.AuthenticationRequest.RedirectToProvider()
at MyProject.Services.Authentication.OpenIdAuthenticationService.GetOpenIdPersonaDetails(Uri serviceUri) in C:\Users\Pure Krome\Documents\Visual Studio 2008\Projects\MyProject\Projects\Services\Authentication\OpenIdAuthenticationService.cs:line 108
at MyProject.Mvc.Controllers.AuthenticationController.Authenticate() in C:\Users\Pure Krome\Documents\Visual Studio 2008\Projects\MyProject\Projects\MVC Application\Controllers\AuthenticationController.cs:line 69
TargetSite :Void AbortInternal()
A first chance exception of type 'System.Threading.ThreadAbortException' occurred in Ackbar.Mvc.DLL
An exception of type 'System.Threading.ThreadAbortException' occurred in Ackbar.Mvc.DLL but was not handled in user code
Это нормальное поведение и возможно ли корректное прерывание вместо (как выглядит) внезапного внезапного прерывания?
Обновлять
Пока это обычная перепись, это по дизайну. Так что мне интересно, возможно ли, что мы могли бы ответить на этот вопрос и посмотреть, можем ли мы настроить код, чтобы не было ощущения, будто мы завершаем поток преждевременно и изящно выходим ... Возможно? Примеры кода?
См. Соответствующий ответ-конец-считается-вредным
Ответы 5
Не существует такого понятия, как «изящный» прерывание. Однако вы можете просто Flush () ответ вместо его завершения и позволить фреймворку позаботиться о закрытии соединения за вас. В этом случае я предполагаю, что вы хотите, чтобы ответ был отправлен клиенту, то есть в типичном случае.
Согласно MSDN, вызов Response.End () вызывает исключение ThreadAbortException, когда ответ заканчивается преждевременно. Вы действительно должны вызывать Response.End () только тогда, когда вы хотите, чтобы исключение возникло.
Мне всегда было интересно, каково точное определение «преждевременно» в этом контексте ... Это где-нибудь задокументировано? Я всегда понимал, что это означает «есть ли код, который нужно выполнить после вызова Response.End ()».
Да, это действительно задумано. У Microsoft есть даже задокументированный. Как еще вы могли бы остановить выполнение остальной части вашей программы?
См. Ответы на вопрос ответ-конец-считается-вредным
Нет ничего изначально безобразного в том, что исключение рекурсивно поднимается вверх по вашему стеку, чтобы остановить текущее выполнение. Конечно, не больше, чем вы выбрасываете исключение и перехватываете его в каком-то более низком месте в вашем исключении.
Я бы посмотрел на фильтрацию из вашего журнала. Если вы используете мониторинг работоспособности ASP.Net, вы можете настроить / сопоставить каждое исключение с заданным поставщиком (журнал событий, почта и т. д.), Чтобы контролировать, получаете ли вы уведомление об исключениях прерывания потока или нет. Если это пользовательское ведение журнала, я бы просто добавил if, чтобы проверить это.
Обратите внимание, что вы не можете съесть ThreadAbortException, поэтому, даже если ваш код ведения журнала делает что-то вроде catch(Exception e) { // log exception and then do not throw again }, ThreadAbortException все равно будет снова вызван фреймворком после выхода вашего блока catch.
Я всегда стараюсь избегать исключений, ЕСЛИ не существует непредвиденный. С моей точки зрения, если мы хотим ПЕРЕНАПРАВИТЬ, это ожидал ... так что так, мы знаем, что пытаемся сделать (остановить текущий материал, перейти к новому URI) ... поэтому я не понимаю, почему они сделали это не изящно конец.
Так что я думаю, что склонен согласиться с вами, что вы не должны проектировать библиотеки таким образом. тем не менее, я не могу придумать, как это можно было бы без исключения реализовать в среде .Net. В этом случае, ожидаемом или нет, вызывается исключение.
Не используйте метод Response.End (), потому что он использует Application.End () и останавливает приложение. Далее используйте HTTP-запрос или ответ, нарушающий жизненный цикл страницы. Используйте HttpContext.Current.Response.Close () или HttpContext.Current.ApplicationInstance.CompleteRequest ();
пожалуйста, добавьте источник. это поможет более ясно, если кто-то ссылается
HttpContext.Current.Response.Clear (); HttpContext.Current.Response.ClearHeaders (); HttpContext.Current.Response.Buffer = true; HttpContext.Current.Response.ContentType = "приложение / ms-excel"; HttpContext.Current.Response.AddHeader ("Content-Disposition" , "вложение; имя_файла = " + FileToDownLoad.Name); HttpContext.Current.Response.Charset = "utf-8"; HttpContext.Current.Response.WriteFile (FileToDownLoad.FullNa меня); HttpContext.Current.Response.Flush (); HttpContext.Current.Response.Close (); HttpContext.Current.ApplicationInstance.CompleteRequest ();
Я использовал все вышеупомянутые изменения, но все же у меня возникала такая же проблема в моем веб-приложении.
Затем я связался со своим провайдером хостинга и попросил их проверить, не блокирует ли какое-либо программное обеспечение или антивирус наши файлы для передачи через HTTP. или Интернет-провайдер / сеть не разрешает передачу файла.
Они проверили настройки сервера и обошли «общий брандмауэр центра обработки данных» для моего сервера, и теперь наше приложение начало скачивать файл.
Надеюсь, этот ответ кому-то поможет. Это сработало для меня.
Привет, В дополнение к ответам ниже вы можете проверить следующее: support.microsoft.com/kb/312629/EN-US