Ten artykuł KB mówi, że ASP.NET Response.End()
przerywa wątek.
Odbłyśnik pokazuje, że wygląda to tak:
public void End()
{
if (this._context.IsInCancellablePeriod)
{
InternalSecurityPermissions.ControlThread.Assert();
Thread.CurrentThread.Abort(new HttpApplication.CancelModuleException(false));
}
else if (!this._flushing)
{
this.Flush();
this._ended = true;
if (this._context.ApplicationInstance != null)
{
this._context.ApplicationInstance.CompleteRequest();
}
}
}
Wydaje mi się to dość trudne. Jak mówi artykuł KB, żaden kod w poniższej aplikacji Response.End()
nie zostanie wykonany, co narusza zasadę najmniejszego zdziwienia. To prawie jak Application.Exit()
w aplikacji WinForms. Wyjątek przerwania wątku spowodowany przez Response.End()
nie jest możliwy do złapania, więc otoczenie kodu w try
... finally
nie spełni.
Zastanawiam się, czy zawsze powinienem tego unikać Response.End()
.
Czy ktoś może zasugerować, kiedy powinienem użyć Response.End()
, kiedy Response.Close()
i kiedy HttpContext.Current.ApplicationInstance.CompleteRequest()
?
ref: wpis na blogu Ricka Strahla .
Na podstawie otrzymanych informacji moja odpowiedź brzmi: tak, Response.End
jest szkodliwa , ale jest przydatna w niektórych ograniczonych przypadkach.
- użyć
Response.End()
jako rzut niemożliwy do złapania, aby natychmiast zakończyćHttpResponse
wyjątkowe warunki. Może być przydatny również podczas debugowania. UnikajResponse.End()
rutynowych odpowiedzi . - użyj,
Response.Close()
aby natychmiast zamknąć połączenie z klientem. Zgodnie z tym postem na blogu MSDN ta metoda nie jest przeznaczona do normalnego przetwarzania żądań HTTP. Jest bardzo mało prawdopodobne, że powinieneś nazwać tę metodę. - użyj,
CompleteRequest()
aby zakończyć normalne żądanie.CompleteRequest
powoduje, że potok ASP.NET przeskakuje doEndRequest
zdarzenia po zakończeniu bieżącegoHttpApplication
zdarzenia. Więc jeśli zadzwoniszCompleteRequest
, a następnie napisz coś więcej w odpowiedzi, zapis zostanie wysłany do klienta.
Edycja - 13 kwietnia 2011 r
Dalsza przejrzystość jest dostępna tutaj:
- Przydatny post na blogu MSDN
- Przydatna analiza autorstwa Jona Reida
Response.Redirect
i Server.Transfer
zarówno połączenia Response.End
i należy również unikać.
Response.End
ThreadAbortException
.