Нестандартная обработка исключений

Многие библиотеки и некоторые компиляторы обрабатывают исключения нестандартным образом. Большинство имитирует парадигму try/catch с помощью макросов, но не организует правильной раскрутки стека за счет вызова деструкторов конструированных объектов. Некоторые реализации ориентированы на конкретные типы компьютеров и операционных систем.

К сожалению, многие компиляторы претендуют на стандартную обработку исключений, но не во всем следуют каноническим правилам. На своем горьком опыте я узнал, что обработку исключений желательно тестировать, если вы делаете нечто хоть сколько-нибудь нестандартное (даже если оно должно быть стандартным). Если вы окажетесь в подобной ситуации, окажите услугу всем нам: наймите разработчика такого компилятора якобы для серьезного проекта и заставьте его писать и отлаживать код обработки исключений для его собственного компилятора в течение ближайших пяти лет. А еще лучше, заставьте его перенести в свой компилятор код, идеально работающий на другом

компиляторе.

Если по какой-либо причине вам придется заниматься нестандартной обработкой исключений, больше всего проблем вызовет освобождение памяти от динамических объектов, которые были созданы до возникновения исключения и внезапно стали недоступными переменным. Именно для этой цели используется 99% обработки исключений в реальной жизни, да еще изредка требуется закрыть открытые файлы. Вы можете либо создать хитроумные структуры данных, которые перемещают новые

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

воспользоваться методикой сборки мусора, описанной в последней части книги. Оба подхода выглядят в равной степени отталкивающе, так что выбирайте сами.