Неуправляемый код Visual C ++: использовать исключения / EHa или / EHsc для C ++?

Question

Если я создаю новый проект в неуправляемом C ++, Visual Studio 2008 или более поздней версии, какую модель обработки исключений я хочу использовать?

Я понимаю, что опция / EHa приводит к менее эффективному коду,а также перехватывает исключения SEH, верно?

Так что я избежал этой опции и обычно использую / EHsc, так что я перехватываю только исключения C ++, которые на самом деле выбрасываются, и не перехватывает нарушения доступа и другиеструктурированные исключения в обработчиках catch (...).Если в моем коде есть нарушение прав доступа, я не хочу, чтобы оно маскировалось с помощью catch (...) {}.

Я пишу код другим пользователям, которым нужно catch (...) {}ничего не делать, и они даже хотят, чтобы это делалось, если есть нарушение прав доступа, что кажется мне очень плохой идеей.Если есть ошибка из-за плохого кодирования, вы не хотите засунуть пальцы в уши и громко сказать: «La la la la la!»чтобы у вас не было сбоев программы?На самом деле, если код в настоящее время находится в плохом состоянии из-за ошибки кодирования, действительно ли вы хотите, чтобы код продолжался?

Итак, моя общая мысль заключается в том, что / EHa создает более крупный / более медленный код и позволяет программистамчтобы избежать написания кода, который, если присутствует фатальная ошибка, продолжит работать в неопределенном состоянии.

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

Пожалуйста, взвесьте свои мысли.

Answer 1

/ ЭХА делает две вещи. Прежде всего, он подавляет оптимизацию, которая исключает фильтры исключений, которые автоматически вызывают деструкторы локальных переменных класса, если анализатор кода не может увидеть какой-либо код, который может вызвать исключение C ++. Это делает разматывание стека безопасным для любого исключения, а не только для исключения C ++. Затраты на эти фильтры исключений составляют время на x86 и пространство на x86 и x64.

И да, он изменяет поведение catch (...), теперь он также фильтрует все исключения SEH, а не только C ++. Это действительно азартная игра, потому что вы ловите все очень неприятные вещи, асинхронные аппаратные исключения. Хотя я лично не думаю, что перехват всех исключений C ++ также очень оправдан, у вас все еще есть смутное представление о том, в какой степени изменилось состояние программы и почему это не удалось.

Реально, вам нужно переключиться на использование __try/__except, чтобы вы могли написать свой собственный фильтр исключений и избегать выявления плохих. Код исключения для исключений C ++ - 0xe04d5343 («MSC»). Использование _set_se_translator () было бы другим подходом.

Answer 2

Я использую / EHa, потому что это безопасно при взаимодействии .NET, тогда как / EHsc может и не быть;см. Деструкторы, не вызываемые, когда собственное (C ++) исключение распространяется, например, на компонент CLR .

Однако, если для определенного бита кода дополнительная производительность действительно имеет значение, и вам это не нужно.Совместимость с NET (или любым другим), но, конечно, / EHsc звучит нормально.

Ни / EHsc, ни / EHa не отлавливают большинство ошибок памяти, поэтому их использование для обнаружения нарушений доступа - безнадежный случай.