Основы программирования в Win32API. Марапулец Ю.В. - 113 стр.

UptoLike

Составители: 

// диспетчеризации (OLE-автоматизации)
{
...
}
catch(CUserException *e) // пользовательское исключение
{
...
}
catch(CException *e) // данный блок должен следовать после
// предыдущих блоков, иначе компилятор выдаст код ошибки
{
...
}
catch (...) // перехват всех исключений!!!
{
...
}…
В этом примере все классы, производные от класса CException, включены
в блоки catch. Однако на практике столь прямолинейные процедуры обработки
исключений, как правило, не применяются. В этой связи необходимо отметить
два следующих момента [2]:
1. После блоков catch, использующих производные классы, должен сле-
довать оператор catch (CException *e). В случае нарушения указанного порядка
компилятор выдает предупреждение о том, что блоки, следующие после опе-
ратора catch (CException *e), не будут распознаны, поскольку исключение уже
перехвачено блоком CException.
2. После всех остальных операторов должен следовать блок catch (...),
перехватывающий все исключения, которые не были обработаны предыдущи-
ми блоками классов семейства CException.
Задача поиска процедуры обработки исключения становится более слож-
ной, когда процесс находится в состоянии отладки, поскольку операционная
система передает управление отладчику еще до начала поиска обработчиков,
находящихся в самой программе. Обычно отладчик использует этот режим для
обработки пошаговых и контрольных исключений, что дает возможность
пользователю проанализировать контекст программы перед возобновлением ее
выполнения.
Если отладчик принимает решение не обрабатывать исключения на стадии
раннего оповещения, система возвращается к процессу и ищет обработчик ис-
ключений внутри него самого. При условии, что процесс также отвергает исклю-
чение, система дает отладчику повторную возможность обработать эту, теперь
уже более серьезную, ситуацию. Но если отладчик отвергает исключение по-
вторно, система берет управление на себя и вырабатывает собственный ответ,
который обычно заключается в приказе уничтожить процесс.
Вместо того чтобы непосредственно применять блоки try/catch, вы мо-
113
                            // диспетчеризации (OLE-автоматизации)
{
     ...
}
catch(CUserException *e)                   // пользовательское исключение
{
       ...
}
catch(CException *e)                  // данный блок должен следовать после
            // предыдущих блоков, иначе компилятор выдаст код ошибки
{
       ...
}
catch (...)                       // перехват всех исключений!!!
{
       ...
}…
     В этом примере все классы, производные от класса CException, включены
в блоки catch. Однако на практике столь прямолинейные процедуры обработки
исключений, как правило, не применяются. В этой связи необходимо отметить
два следующих момента [2]:
     1. После блоков catch, использующих производные классы, должен сле-
довать оператор catch (CException *e). В случае нарушения указанного порядка
компилятор выдает предупреждение о том, что блоки, следующие после опе-
ратора catch (CException *e), не будут распознаны, поскольку исключение уже
перехвачено блоком CException.
     2. После всех остальных операторов должен следовать блок catch (...),
перехватывающий все исключения, которые не были обработаны предыдущи-
ми блоками классов семейства CException.
     Задача поиска процедуры обработки исключения становится более слож-
ной, когда процесс находится в состоянии отладки, поскольку операционная
система передает управление отладчику еще до начала поиска обработчиков,
находящихся в самой программе. Обычно отладчик использует этот режим для
обработки пошаговых и контрольных исключений, что дает возможность
пользователю проанализировать контекст программы перед возобновлением ее
выполнения.
     Если отладчик принимает решение не обрабатывать исключения на стадии
раннего оповещения, система возвращается к процессу и ищет обработчик ис-
ключений внутри него самого. При условии, что процесс также отвергает исклю-
чение, система дает отладчику повторную возможность обработать эту, теперь
уже более серьезную, ситуацию. Но если отладчик отвергает исключение по-
вторно, система берет управление на себя и вырабатывает собственный ответ,
который обычно заключается в приказе уничтожить процесс.
     Вместо того чтобы непосредственно применять блоки try/catch, вы мо-

                                    113