Možná objevuji Ameriku, ale přinejmenším vývojářům v Rebexu doporučuji tento článek přečíst a začít se jím řídit.
Response.End jsem dlouho nepotřeboval používat (kromě ukončování stránek při ladění) a setkávám se s ním teprve v poslední době, kdy jsme si navykli exportovat data z ASPX stránek dle následujícího scénáře:
(scénář je převzat přímo z jendoho dema k DevExpress PivotGridu)
MemoryStream vystup = ZiskejVystupniData();
Response.Clear();
//...nastavení Response HTTP headeru...
Response.BinaryWrite(vystup.GetBuffer);
Response.End();
Pokud na dané stránce explicitně odchytáváte výjimky, zjistíte, že hází ThreadAbortException
(pokud ale výjimku neodchytáváte, stránka nespadne a v vše funguje bez viditelných problémů).
Článek v MSDN bázi znalostí doporučuje namísto Response.End použít
HttpContext.Current.ApplicationInstance.CompleteRequest.
To obvykle zafunguje, dosud s tím nemám žádné negativní zkušenosti a doporučuji tento způsob preferovat.
UPDATE: uprostřed jenoho diskusního příspěvku jsem se dočetl (a v praxi si ověřil), že i CompleteRequest má svou nevýhodu: narozdíl od Response.End či Response.Close nezajistí, aby se po zavolání CompleteRequest už NIC nezapsalo do Response.Output streamu. K zápisu může dojít následným voláním Response.Write ale do streamu se dostane i text vyrenderovaný z .ASPX souboru. Naštěstí se tento výstup dá celkem dobře potlačit pomocí override metod RaisePostBackEvent a Render - blíže viz pěkném shrnujícím článku na toto téma.
Interní poznámka pro vývojáře v Rebexu:
Ukončování stránek pomocí HttpContext.Current.ApplicationInstance.CompleteRequest bohužel nezafunguje v starých projektech, kde se používá UcPage.
V takových situacích doporučuji odchytávat při volání Response.Endu výjimku ThreadAbortException a zahazovat ji.