Как я могу поймать неверный вызов FGetPOS в виде исключения C ++ на Windows?
-
15-11-2019 - |
Вопрос
в Visual C ++ 2008, я хочу «поймать» исключение, сгенерированное, как показано здесь:
try {
int foo = 20;
::fgetpos(0, (fpos_t*)&foo);
}
//...
.
Вот регулировки, которые я предпринял, чтобы попытаться получить успешный улов:
- seh активирован (/ eha)
- Я добавил улов (...)
- Я добавил _set_se_translator Вектор.
- Я добавил / настроен на синтаксис SEH: __hry / __except (Exception_execute_Handler)
Короче, я пробовал «все в книге», и я до сих пор не могу поймать исключение. Если я заменил вызов
::fgetpos
сint hey = foo / 0
, вдруг все вышеперечисленные методы работают, как ожидалось. Таким образом, исключение, с которым я имею дело от::fgetpos
, является как-то «очень особенным».Может кто-то объяснить, почему это :: FgetPOPS ошибка кажется беззащитаемыми, и как вокруг него работать?
Обновление При выполнении в IDE vs, выходное окно не называет исключение. Все это говорит: Библиотека времени выполнения Microsoft Visual Studio Custome обнаружена фатальная ошибка в MyProgram.exe.
Не очень полезно. Когда я запускаю приложение консоли из командной строки, я получаю аварийный диалог. Раздел «Детали проблемы» диалога включает эту информацию:
Проблема Имя события: Bex
Смещение исключения: 0002fd30
Код исключения: C0000417
C0000417 Данные исключения: 00000000
Дополнительная информация 1: 69Ad
Дополнительные данные 2: 69ADDFB19767B2221C8E3E7A5CD2F4AE
Дополнительная информация 3: B1FF Дополнительная информация 4: b1ffca30cadddc78c19f19b6d150997f
Решение
Since the code in your dump corresponds to STATUS_INVALID_CRUNTIME_PARAMETER
, try _set_invalid_parameter_handler
Другие советы
Most likely, the runtime catches it for you and issues a debug dialog without returning or propagating the exception- that is a CRT call and they may add whatever exception catching code in there they like. It's well within Visual Studio's rights to catch a hardware exception inside a library function, especially if you are running from within the IDE or in debug mode, then it is expected of the runtime.
Of course, when you divide by zero, then there is no library call here to write that extra catching code.