sprintf(p, "Attempt to %s data at address %p", pER- >ExceptionInformation[0] ? "write" : "read", pER- >ExceptionInformation[1]);
break;
default;
break;
}
MessageBox(NULL, szBuf, "Exception", MB_OK | MB_ICONEXCLAMATION);
return(EXCEPTION_CONTINUE_SEARCH); }
Элемент ContextRecord структуры EXCEPTION_POINTERS указывает на структуру CONTEXT (см. главу 7), содержимое которой зависит от типа процессора.
С помощью этой структуры, в основном содержащей по одному элементу для каж дого регистра процессора, можно получить дополнительную информацию о возник шем исключении. Увы, это потребует написания машинно-зависимого кода, способ ного распознавать тип процессора и использовать подходящую для пего структуру CONTEXT. При этом Вам придется включить в код набор директив #ifdef для разных типов процессоров. Структуры CONTEXT для различных процессоров, поддерживае мых Windows, определены в заголовочном файле WinNT.h,
Программные исключения
До сих пор мы рассматривали обработку аппаратных исключений, когда процессор перехватывает некое событие и возбуждает исключение. Но Вы можете и сами гене рировать исключения. Это еще один способ для функции сообщить о неудаче выз вавшему ее коду, Традиционно функции, которые могут закончиться неудачно, воз вращают некое особое значение — признак ошибки. При этом предполагается, что код, вызвавший функцию, проверяет, не вернула ли она это особое значение, и, если да, выполняет какие-то альтернативные операции. Как правило, вызывающая функция проводит в таких случаях соответствующую очистку и в свою очередь тоже возвра щает код ошибки. Подобная передача кодов ошибок по цепочке вызовов резко услож няет написание и сопровождение кода.
Альтернативный подход заключается в том, что при неудачном вызове функции возбуждают исключения. Тогда написание и сопровождение кода становится гораздо проще, а программы работают намного быстрее. Последнее связано с тем, что та часть кода, которая отвечает за контроль ошибок, вступает в действие лишь при сбоях, т. e. в исключительных ситуациях.
К сожалению, большинство разработчиков не привыкло пользоваться исключени ями для обработки ошибок. На то есть двс причины Во-первых, многие просто не знакомы с SEH. Если один разработчик создаст функцию, которая генерирует исклю чение, а другой не сумеет написать SEH-фрейм для перехвата этого исключения, его приложение при неудачном вызове функции будет завершено операционной системой
Вторая причина, по которой разработчики избегают пользоваться SEH, — невоз можность его переноса на другие операционные системы. Ведь компании нередко выпускают
программные продукты, рассчитанные на несколько операционных сис тем, и, естественно, предпочитают работать с одной базой исходного кода для каж дого продукта. А структурная обработка исключений — это технология, специфич ная для Windows.
Если Вы все же решились на уведомление об ошибках через исключения, я аппло дирую этому решению и пишу этот раздел специально для Вас. Давайте для начала посмотрим на семейство Неар-функции (HeapCreate, НеарАllос и т. д.). Наверное, Вы помните из главы 18, что они предлагают разработчику возможность выбора. Обыч но, когда их вызовы заканчиваются неудачно, они возвращают NULL, сообщая об ошибке. Но Вы можете передать флаг HEAP_GENERATE_EXCEPTIONS, и тогда при не удачном вызове Неарфункция не станет возвращать NULL; вместо этого она возбу дит программное исключение STATUS_NO_MEMORY, перехватываемое с помощью SEH-фрейма.
Чтобы использовать это исключение, напишите код блока try так, будто выделе ние памяти всегда будет успешным; затем — в случае ошибки при выполнении дан ной операции Вы сможете либо обработать исключение в блоке except, либо зас тавить функцию провести очистку, дополнив блок try блоком finally. Очень удобно!
Программные исключения перехватываются точно так же, как и аппаратные, Ина че говоря, все, что я рассказывал об аппаратных исключениях, в полной мере отно сится и к программным исключениям.
В этом разделе основное внимание мы уделим тому, как возбуждать программные исключения в функциях при неудачных вызовах. В сущности, Вы можете реализовать свои функции по аналогии с Heap-функциями: пусть вызывающий их код передаст специальный флаг, который сообщает функциям способ уведомления об ошибках.
Возбудить программное исключение несложно — достаточно вызвать функцию
RaiseException:
VOTD RaiseException( OWORD dwExceptionCode, DWORD dwExceptionFlags, DWORD nNumberOfArguments, CONST ULONG_PTR *pArguments);
Ее первый параметр, dwExceptionCode, — значение, которое идентифицирует ге нерируемое исключение. HeapAlloc передает в нем STATUS_NO_MEMORY. Если Вы определяете собственные идентификаторы исключений, придерживайтесь формата, применяемого для стандартных кодов ошибок в Windows (файл WinError.h) Не забудь те, что каждый такой код представляет собой значение типа DWORD, его поля описа ны в таблице 24-1. Определяя собственные коды исключений, заполните все пять его полей
биты 31 и 30 должны содержать код степени «тяжести»; бит 29 устанавливается в 1 (0 зарезервирован для исключений, определяемых
Microsoft, вроде STATUS_NO_MEMORY для HeapAlloc);
бит 28 должен быть равен 0;
биты 27-l6 должны указывать один из кодов подсистемы, предопределенных
Microsoft;
биты 15-0 Moгут содержать произвольное значение, идентифицирующее ту часть Вашего приложения, которая возбуждает исключение.
Второй параметр функции RaiseException — dwExceptionFlags — должен быть либо 0, либо EXCEPTION_NONCONTINUABLE. В принципе этот флаг указывает, может ли фильтр исключений вернуть EXCEPTION_CONTINUE_EXECUTION в ответ на дан ное
исключение. Если Вы передаете в этом параметре нулевое значение, фильтр мо жет вернуть EXCEPTION_CONTlNTJE_EXECUTION В нормальной ситуации это заста вило бы поток снова выполнить машинную команду, вызвавшую программное исклю чение Однако Microsoft пошла на некоторые ухищрения, и поток возобновляет вы полнение с оператора, следующего за вызовом RaiseExcepiton
Но, передав функции RaiseException флаг EXCEPTION_NONCONTINUABLE, Вы со общаете системе, что возобновить выполнение после данного исключения нельзя. Операционная система использует этот флаг, сигнализируя о критических (фаталь ных) ошибках. Например, HeapAlloc устанавливает этот флаг при возбуждении про граммного исключения STATUS_NO_MEMORY, чтобы указать системе: выполнение продолжить нельзя Ведь если вся память занята, выделить в нсй новый блок и про должить выполнение программы не удастся.
Если возбуждается исключение EXCEPTION_NONCONTINUABLE, а фильтр все же возвращает EXCEPTION_CONTINUE EXECUTION, система генерирует новое исключе ние EXCEPTION_NONCONTINUABLE_EXCEPTION.
При обработке программой одного исключения вполне вероятно возбуждение нового исключения И смысл в этом есть. Раз уж мы остановились на этом месте, за мечу, что нарушение доступа к памяти возможно и в блоке finally, и в фильтре исклю чений, и в обработчике исключений. Когда происхидит нечто подобное, система со здает список исключений. Помните функцию GetExceptionlnformation? Она возвращает адрес структуры EXCEPTION_POINTERS Ее элемент ExceptionRecord указывает на струк туру EXCEPTION_RECORD, которая в свою очередь тоже содержит элемент Exception-
Record. Он указывает на другую структуру EXCEPTION_RECORD, где содержится ин формация о предыдущем исключении.
Обычно система единовременно обрабатывает только одно исключение, и эле мент ExceptionRecord равен NULL. Ho если исключение возбуждается при обработке другого исключения, то в первую структуру EXCEPTION_RECORD помещается инфор мация о последнем исключении, а ее элемент ExecptionRecord указывает на аналогич ную структуру с аналогичными данными о предыдущем исключении. Если есть и дру гие необработанные исключения, можно продолжить просмотр этого связанного списка структур EXCEPTION_RECORD, чтобы определить, как обработать конкретное исключение.
Третий и четвертый параметры (nNumberOfArguments и pArguments) функции Raise Exception позволяют передать дополнительные данные о генерируемом исключении Обычно это не нужно, и pArguments передается NULL; тогда RaiseException игнори рует параметр nNumberOfArguments. А если Вы передаете дополнительные аргументы, nNumberOfArguments должен содержать число элементов в массиве типа ULONGPTR, на который указываетр pArguments. Значение nNumberOfArguments не может быть боль ше
EXCEPTION_MAXIMUM_PARAMETERS (в файле WinNT.h этот идентификатор опре делен равным 15).
При обработке исключения написанный Вами фильтр — чтобы узнать значения nNumberOfArguments и pArguments — может ссылаться на элементы NumberParameters и Exceptionlnformation структуры EXCEPTION_RECORD