В этой статье KB говорится, что ASP.NET Response.End()
прерывает поток.
Отражатель показывает, что он выглядит так:
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();
}
}
}
Это кажется мне довольно суровым. Как говорится в статье в KB, любой код в приложении, следующий за Response.End()
, не будет выполнен, что нарушает принцип наименьшего удивления. Это почти как Application.Exit()
в приложении WinForms. Исключение прерывания потока, вызванное Response.End()
, не является захватывающим, поэтому окружающий код в try
... finally
не будет удовлетворять.
Это заставляет меня задаться вопросом, следует ли всегда избегать Response.End()
.
Может ли кто-нибудь предложить, когда следует использовать Response.End()
, когда Response.Close()
и когда HttpContext.Current.ApplicationInstance.CompleteRequest()
?
ref: Запись в блоге Рика Страхла.
На основании ввода, который я получил, мой ответ: Да, Response.End
вреден, но он полезен в некоторых ограниченных случаях.
- используйте
Response.End()
как неуловимый бросок, чтобы немедленно завершитьHttpResponse
в исключительных условиях. Может быть полезно и при отладке. ИзбегайтеResponse.End()
для завершения стандартных ответов. - используйте
Response.Close()
, чтобы немедленно закрыть соединение с клиентом. Per это сообщение в блоге MSDN, этот метод не предназначен для обычной обработки запросов HTTP. Его маловероятно, что у вас будет веская причина назвать этот метод. - используйте
CompleteRequest()
для завершения обычного запроса.CompleteRequest
заставляет конвейер ASP.NET перейти к событиюEndRequest
после завершения текущего событияHttpApplication
. Поэтому, если вы вызываетеCompleteRequest
, а затем пишите что-то еще в ответ, запись будет отправлена клиенту.
Редактировать - 13 апреля 2011 г.
Дополнительная ясность доступна здесь:
- Полезный пост в блоге MSDN
- Полезный анализ Джона Рида