Este artigo da Response.End()
Base de dados de KB diz que o ASP.NET interrompe um thread.
Refletor mostra que ele se parece com isso:
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();
}
}
}
Isso parece muito duro para mim. Como o artigo da KB diz, qualquer código no aplicativo a seguir Response.End()
não será executado e isso viola o princípio de menor espanto. É quase como Application.Exit()
em um aplicativo WinForms. A exceção de cancelamento de encadeamento causada por Response.End()
não é capturável, portanto, cercar o código em try
... finally
não será satisfatório.
Isso me faz pensar se devo sempre evitar Response.End()
.
Alguém pode sugerir, quando devo usar Response.End()
, quando Response.Close()
e quando HttpContext.Current.ApplicationInstance.CompleteRequest()
?
ref: entrada no blog de Rick Strahl .
Com base nas informações recebidas, minha resposta é: Sim, Response.End
é prejudicial , mas é útil em alguns casos limitados.
- use
Response.End()
como um lançamento inalcançável, para encerrar imediatamente oHttpResponse
em condições excepcionais. Também pode ser útil durante a depuração. EviteResponse.End()
completar respostas de rotina . - use
Response.Close()
para fechar imediatamente a conexão com o cliente. Por esta postagem do blog do MSDN , esse método não se destina ao processamento normal de solicitações HTTP. É altamente improvável que você tenha um bom motivo para chamar esse método. - use
CompleteRequest()
para finalizar uma solicitação normal.CompleteRequest
faz com que o pipeline do ASP.NET pule para oEndRequest
evento, após a conclusão doHttpApplication
evento atual . Portanto, se você ligarCompleteRequest
, escreva algo mais para a resposta, a gravação será enviada ao cliente.
Editar - 13 de abril de 2011
Mais clareza está disponível aqui:
- Postagem útil no Blog do MSDN
- Análise útil por Jon Reid
Response.Redirect
e Server.Transfer
ambos chamam Response.End
e também devem ser evitados.
Response.End
ThreadAbortException
bom.