Допустим, я пишу оболочку для объекта OpenGL.
Шаг 1. Не делайте этого. Я знаю, это звучит легкомысленно, но, пожалуйста, не надо. Я могу понять, что мне нужен управляемый тип объекта, например unique_ptr, но для объектов OpenGL. Но любая упаковка за пределами этого почти наверняка навредит вам гораздо больше, чем поможет. Особенно если абстракция неверна. Взаимодействия между объектами и механизмами OpenGL, как правило, не подходят для такого рода вещей.
Вы получите гораздо больше от непосредственного использования вызовов OpenGL с прямым доступом к состоянию , чем обертывание функций OpenGL за некоторым объектоминтерфейс. Ваш код волшебным образом не улучшается только благодаря использованию функций-членов.
, когда это происходит, метод, вызывающий функцию OpenGL, возвращает код ошибки или выдает исключение
Шаг 2: Не делай этого тоже. Большинство ошибок OpenGL являются ошибками использования (то есть вы использовали API неправильно). И ошибки использования , а не должны обрабатываться как исключения C ++. Исключением должны быть условия, такие как неверный ввод или текстура с неожиданным форматом. Вещи, которые приходят из-за пределов кода. Использование исключений для обработки ошибок программирования, как правило, не является полезной идеей.
Если вам нужно отладить приложение OpenGL, есть два основных способа их обработки. Для повседневной проверки вы должны использовать Debug Output , чтобы регистрировать любые ошибки, которые вы получаете. Это особенно полезно для сборок типа «релиз» (хотя вам все еще нужно использовать контекст отладки для обеспечения поддержки вывода отладки).
Если вы получили ошибку, вы можете загрузитьRenderdoc или аналогичный инструмент, который может точно сказать, где была сгенерирована ошибка. В качестве альтернативы, вы можете настроить вывод отладки так, чтобы он выдавал вам синхронные сообщения об ошибках вместо асинхронных ошибок, так что вы можете просто установить точку останова в середине, откуда возникла ошибка. В любом случае, вы должны иметь возможность легко отследить его с помощью минимального специализированного кода и, самое главное, без обёрток функций.
Действительно, Renderdoc и подобные инструменты гораздо более полезны для отслеживания ошибок OpenGL в сборках релизов, чемвсе, что можно разумно написать сам. Вы можете получить трассировку всех ваших вызовов OpenGL со значениями параметров и т.п. Это просто лучший способ обработки ошибок.