Например, с ситуациями, возникающими в функциях математической

Библиотеки, можно связать семейство исключений MathError, включающее

Исключения Overflow, Underflow, Zerodivide и т.п.

Один из способов такой группировки состоит в определении

перечислимого типа данных MathError с соответствующими значениями:

enum MathError { Overflow, Underflow, Zerodivide, /*.....*/ };

//.....

try {

//.....

MathError m;

Throw m;

}

catch(MathError m) {

switch (m) {

case Overflow: /*..... */ break;

case Underflow: /*..... */ break;

case Zerodivide: /*..... */ break;

default: /*..... */;

}

}

Объектно-ориентированный подход подразумевает использование

механизмов наследования и виртуальных функций:

class MathError { };

class Overflow: public MathError { };

class Underflow: public MathError { };

class Zerodivide: public MathError { };

//.....

try {

//.....

}

catch(Overflow) {

// обработка Overflow и его потомков

}

catch(MathError) {

// обработка любого MathError, кроме Overflow и его потомков

}

Здесь все исключения, кроме Overflow, обрабатываются единообразно, как

MathError. Если требуется полиморфизм, то исключение в обработчик можно

Передавать по ссылке, либо использовать указатели.

Наградой за построение иерархии исключений является ее

Технологичность при сопровождении больших программ. Представьте себе,

Например, обработку всех исключений для стандартной математической

Библиотеки. Без группировки на основе наследования это приводит к длинным

последовательностям обработчиков:

try {

//.....

}

catch(Overflow) { /*..... */ }

catch(Underflow) { /*..... */ }

catch(Zerodivide) { /*..... */ }

//.....

Весьма часто реакция на разные исключения будет одинаковой. Такая

Ситуация вызывает раздражение из-за дублирования кода и содержит опасность

Пропуска некоторых исключений в последовательности обработчиков. Кроме

Того, добавление нового исключения требует модификации и перекомпиляции

Уже работающих программ, что чревато внесением ошибок в ранее отлаженный