Является ли использование Ogre исключений хорошим способом их использования? - PullRequest
5 голосов
/ 29 апреля 2010

Мне удалось пройти всю свою карьеру в программировании игр на C ++, практически не затрагивая исключений, но недавно я работал над проектом с движком Ogre и стараюсь учиться правильно. Я нашел здесь много хороших вопросов и ответов об общем использовании исключений из C ++, но я хотел бы получить здесь несколько внешних мнений о том, хорошо ли использование Ogre и как лучше с ними работать.

Для начала приведем цитату из документации Ogre о своем собственном классе исключения:

OGRE никогда не использует возвращаемые значения для обозначения ошибок. Вместо этого, если возникает ошибка, генерируется исключение, и это объект, который инкапсулирует детали проблемы. Приложение, использующее OGRE, должно всегда следить за тем, чтобы исключения были перехвачены, поэтому все функции механизма OGRE должны находиться в блоке try {} catch (Ogre :: Exception & e) {}.

В самом деле? Каждая функция Ogre может выдать исключение и быть помещена в блок try / catch? В настоящее время это обрабатывается при использовании его при помощи команды try / catch в main, которая покажет окно сообщения с описанием исключения перед выходом. Это может быть немного неудобно для отладки, хотя, поскольку вы не получаете трассировку стека, просто функция, которая выдает ошибку - более важной является функция из нашего кода, которая вызвала функцию Ogre. Если бы это было утверждение в коде Ogre, то оно пошло бы прямо к коду в отладчике, и я был бы в состоянии выяснить, что происходит намного проще - я не знаю, пропустил ли я что-то, что позволило бы мне исключения отладки уже?

Сейчас я начинаю добавлять еще несколько блоков try / catch в наш код, обычно размышляя о том, имеет ли значение, если функция Ogre выдает исключение. Если это что-то, что остановит все, то пусть основной try / catch обработает это и выйдет из программы. Если это не имеет большого значения, перехватите его сразу после вызова функции и дайте программе продолжиться. Одним из недавних примеров этого было построение вектора параметров программы вершины / фрагмента для материалов, применяемых к сущности - если у материала не было никаких параметров, то он генерировал бы исключение, которое я перехватил, а затем проигнорировал, поскольку это не так. Не нужно добавлять в мой список параметров. Кажется ли это разумным способом иметь дело с вещами? Любые конкретные советы по работе с Ogre очень ценятся.

Ответы [ 3 ]

19 голосов
/ 29 апреля 2010

Вам не нужно заключать каждый последний вызов в Ogre в try { ... } catch. Вы делаете это везде, где можете осмысленно разобраться с исключением. В некоторых случаях это может происходить на отдельном сайте вызовов или в какой-то степени в цикле высокого уровня. Если вы нигде не можете разобраться с этим осмысленно, не поймайте его вообще; пусть отладчик вступит во владение.

В частности, вы не должны ловить исключения в main() именно по той причине, по которой вы цитируете (по крайней мере, не во время разработки; вы должны делать это в производстве).

6 голосов
/ 29 апреля 2010

Вы, похоже, не знаете, как отлаживать исключения. Или

  • Вывести VS Debug / Исключения диалог и отметьте исключения C ++ коробка. Это даст вам возможность (появляется диалоговое окно) для отладки, когда исключение.

или

  • Если вы создали источник Ogre, установите точка останова в Ogre::Exception конструктор, и когда он пытается бросить один, вы порвете с стек вызовов, где следующим уровнем вверх является сайт выброса.
6 голосов
/ 29 апреля 2010

Боюсь, я ничего не знаю об Огре, но общее правило обработки исключений состоит в том, что вы ловите исключение как можно дальше от сайта выброса, но не дальше.Однако это возможно только в том случае, если код, генерирующий исключение, использует RAII для наблюдения за выделенными ресурсами.Если в коде используется динамическое распределение для простых указателей или другие формы ручного управления ресурсами, то вам понадобятся блоки try на сайте вызова.Если это так, я бы сказал, что использование исключений - плохая идея.

...