Выяснить источник исключения в C ++ после того, как оно поймано?

Question

Я ищу ответ в MS VC ++.

При отладке большого приложения C ++, которое, к сожалению, очень широко использует исключения C ++. Иногда я ловлю исключение чуть позже, чем на самом деле хочу.

Пример в псевдокоде:

FunctionB()
{
    ...
    throw e;
    ...
}

FunctionA()
{
    ...
    FunctionB()
    ...
}

try
{
    Function A()
}
catch(e)
{
    (<--- breakpoint)
    ...
}

Я могу поймать исключение с точкой останова при отладке. Но я не могу отследить, произошло ли исключение в FunctionA() или FunctionB(), или в какой-либо другой функции. (При условии широкого использования исключений и огромной версии приведенного выше примера).

Одним из решений моей проблемы является определение и сохранение стека вызовов в конструкторе исключений (т.е. до его перехвата). Но это потребовало бы, чтобы я вывел все исключения из этого базового класса исключений. Это также потребовало бы много кода и, возможно, замедлило бы мою программу.

Есть ли более простой способ, который требует меньше работы? Без необходимости менять мою большую кодовую базу?

Есть ли лучшие решения этой проблемы на других языках?

Answer 1

Я использую свои собственные исключения. Вы можете справиться с ними довольно просто - они также содержат текст. Я использую формат:

throw Exception( "comms::serial::serial( )", "Something failed!" );

Также у меня есть второй формат исключений:

throw Exception( "comms::serial::serial( )", ::GetLastError( ) );

Который затем преобразуется из значения DWORD в фактическое сообщение с использованием FormatMessage. Использование формата where / what покажет вам, что произошло и в какой функции.

Answer 2

В случае, если кто-то заинтересован, сотрудник ответил на этот вопрос мне по электронной почте:

Артем написал:

В MiniDumpWriteDump () есть флаг, который может улучшить аварийные дампы, которые позволят видеть полное состояние программы со всеми глобальными переменными и т. Д. Что касается стеков вызовов, я сомневаюсь, что они могут быть лучше из-за оптимизации ... если только Вы выключаете (возможно, некоторые) оптимизации.

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

На самом деле, существует много типов дампа, может быть, вы могли бы выбрать один достаточно маленький, но при этом иметь больше информации http://msdn.microsoft.com/en-us/library/ms680519(VS.85).aspx

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

Я заметил, что некоторые из этих типов дампа не поддерживаются в dbghelp.dll версии 5.1, которую мы используем. Мы могли бы обновить его до последней версии 6.9, хотя я только что проверил лицензионное соглашение для MS Debugging Tools - новый dbghelp.dll все еще можно распространять.

Answer 3

Другие языки? Ну, в Java вы вызываете e.printStackTrace (); Это не намного проще, чем это.