Ten artykuł KB mówi, że ASP.NETResponse.End() przerywa wątek.

Reflektor 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 podaje artykuł KB, każdy kod w aplikacji jest następującyResponse.End() nie zostanie wykonany, a to narusza zasadę najmniejszego zdziwienia. To prawie jakApplication.Exit() w aplikacji WinForms. Wątek przerwał wyjątek spowodowany przezResponse.End() nie da się złapać, więc otaczanie kodu w atry...finally nie zadowoli.

Zastanawiam się, czy zawsze powinienem unikaćResponse.End().

Czy ktoś może zasugerować, kiedy powinienem użyćResponse.End(), gdyResponse.Close() i kiedyHttpContext.Current.ApplicationInstance.CompleteRequest()?

ref:Wpis na blogu Ricka Strahla.

W oparciu o dane, które otrzymałem, moja odpowiedź brzmi:Tak,Response.End jest szkodliwy, ale jest to przydatne w niektórych ograniczonych przypadkach.

posługiwać sięResponse.End() jako rzut niemożliwy do zerwania, aby natychmiast zakończyćHttpResponse w wyjątkowych warunkach. Może być również przydatny podczas debugowania.UniknąćResponse.End() aby zakończyć rutynowe odpowiedzi.posługiwać sięResponse.Close() aby natychmiast zamknąć połączenie z klientem. Zaten post na blogu MSDN, Ta metodanie jest przeznaczony do normalnego przetwarzania żądań HTTP. Jest bardzo mało prawdopodobne, abyś miał dobry powód, aby nazwać tę metodę.posługiwać sięCompleteRequest() aby zakończyć normalne żądanie.CompleteRequest powoduje, że potok ASP.NET przeskakuje do przoduEndRequest wydarzenie, po nurcieHttpApplication wydarzenie zakończone. Więc jeśli zadzwoniszCompleteRequest, a następnie napisz coś więcej do odpowiedzi, zapis zostanie wysłany do klienta.

Edytuj - 13 kwietnia 2011 r

Dalsza przejrzystość jest dostępna tutaj:
- Przydatny post na blogu MSDN
- Przydatna analiza Jon Reid