В этой статье 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
- Полезный анализ Джона Рида