}
}
Этот метод, как по волшебству, вызывается при выгрузке страницы (несмотря на то, что вы не применяли синтаксис событий C#), поскольку атрибут AutoEventWireUp устанавливается равным true (истина) по умолчанию в директиве ‹%@Page%› вашего файла *.aspx.
‹%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs" Inherits="_Default" %›
Как подсказывает имя этого атрибута, при его активизации будет создана необходимая оснастка событий в рамках автоматически генерируемого парциального класса, описанного в этой главе выше. Если установить этот атрибут равным false, не будут вызваны обработчики событий ни для Load, ни для Unload страницы Default (вы можете проверить это непосредственно, установив контрольные точки в пределах обработчиков событий Page_Load() и Page_Unload()).
Однако, если вы используете стандартный синтаксис событий C# для обработки событий Load и Unload, как показано ниже:
public partial class _Default: System.Web.UI.Page {
public _Default() {
// Явный перехват событий Load и Unload.
this.Load += new EventHandler(Page_Load);
this.Unload += new EventHandler(Page_Unload);
}
protected void Page_Load(object sender, EventArgs e) {
Response.Write("Сработало событие Load!");
}
protected void Page_Unload(object sender, EventArgs e) {
// Направить данные в HTTP-ответ здесь невозможно,
// поэтому выполняется запись в локальный файл.
System.IO.File.WriteAllText(@"C:\MyLog.txt", "Выгрузка страницы.");
}
protected void btnPostback_Click(object sender, EventArgs e) {
// Здесь ничего не происходит, но это гарантирует
// вторичный запрос к странице.
}
}
то эти события будут перехвачены вашей страницей независимо от значения, заданного для AutoEventWireup.
В качестве заключительного замечания напомним, что с момента вызова события Unload вы не сможете взаимодействовать с подлежащим отправке HTTP-ответом (если вы попытаетесь вызвать члены объекта HttpResponse, среда выполнения сгенерирует соответствующее исключение). Поэтому здесь обработчик события Unload просто отправляет строку текста в файл на локальном диске C.
Еще одним событием, которое может происходить в цикле существования страницы, является событие Error, которое также работает в паре с делегатом System.EventHandler. Это событие возникает в том случае, когда метод производного от Page типа генерирует исключение, оставшееся без явной обработки. Предположим, что вы обработали событие Click для типа Button на странице, и в пределах обработчика события (здесь он называется btnGetFile_Click) вы пытаетесь записать, содержимое локального файла в HTTP-ответ.
Также предположим, что вам не удалось проверить присутствие этого файла с помощью стандартной технологии структурированной обработки исключений. Если при этом вы предусмотрели обработку события Error страницы, вы получите шанс решить возникшую проблему, чтобы пользователь не увидел безобразную информацию об ошибке. Рассмотрите следующий программный код.
public partial class _Default: System.Web.UI.Page {
public _Default() {
…
// Создание объекта для события Error.
this.Error += new EventHandler(_Default_Error);
void _Default_Error(object sender, EventArgs е) {
// Уничтожение текущего ответа, сообщение об сшибке
// и информирование среды выполнения о том,
// что ошибка обработана.
Response.Clear();
Response.Write("Извините… не могу найти необходимый файл.");
Server.ClearError();
}
protected void btnGetFile_Click(object sender, EventArgs e) {
// Попытка открыть несуществующий файл.
// Это порождает событие Error для данной страницы.
System.IO.File.ReadAllText(@"C:\IDontExist.txt");
}
…
}
Здесь обработчик события Error начинается с очистки всего содержимого имеющегося HTTP-ответа и вывода общего сообщения об ошибке. Чтобы получить доступ к конкретному объекту System.Exception, вы можете использовать метод HttpServerUtility.GetLastError(), доступ к которому обеспечивает унаследованное свойство Server.
void _Default_Error(object sender, EventArgs e) {
Response.Clear();
Response.Write("Извините… не могу найти необходимый файл. ‹br›");
Response.Write(string.Format("Ошибка: ‹b›{0}‹/b›", Server.GetLastError().Message));
Server.ClearError();
}
Наконец, отметьте, что перед выходом из этого общего обработчика ошибок с помощью свойства Server явно вызывается метод HttpServerUtility.ClearError(). Это необходимо, чтобы информировать среду выполнения о том, что проблема вами решена, и дальнейшего вмешательства системы не требуется. Если вы забудете сделать это, конечному пользователю будет предъявлено окно среды выполнения с сообщением об ошибке. На рис. 23.19 показан результат выполнения нашей процедуры обработки ошибок.
Читать дальше