Планируйте время для построения систем отладки
Начиная планировать проект, предусмотрите в нем время для построения систем отладки. С самого начала следует решить, как вы будете реализовывать аварийные обработчики (этой теме посвящена глава 9), разгрузчики файлов данных и другие инструменты, которые понадобятся, чтобы помочь воспроизвести проблемы, сообщенные в полях отчетов об ошибках. Целесообразно обращаться с системами обработки ошибок как со свойством продукта — это позволяет коллегам в компании видеть, как вы подходите к профилактике обработки ошибок.
При планировании системы отладки нужно определить превентивную политику отладки. Первое и наиболее трудное — определить то, как возвращать состояния ошибок в проект. Следует выбрать один способ отладки и его придерживаться. Однажды я столкнулся с проектом (к счастью, я в нем не участвовал), в котором было три различных способа возврата ошибок: возврат значений, исключения setjmp/longjmp и через глобальную переменную ошибки, подобную переменной errno из исполнительной библиотеки языка С. Разработчики этого проекта сталкивались с очень большими трудностями при прослеживании ошибок через границы подсистем.
К сожалению, я не могу рекомендовать какой-либо конкретный способ возврата ошибок как общий для всех ситуаций, потому что разработка в Windows слишком зависит от технологий и чужих компонентов. Такие технологии, как Component Object Model (COM — модель компонентного объекта), предписывают стандарт возврата ошибок. В общем случае, я предпочитаю СОМ-подход, при котором проверяется возвращаемое значение, а не выбрасывается объект типа С++- исключений. Некоторые С++ - разработчики могут со мной и не согласиться, но мои симпатии всегда на стороне простоты и ясности (что очевидно присуще СОМ-подходу).
