Jakie są konsekwencje mieszania modeli obsługi wyjątków w Visual Studio 2010?

Question

Mam niezależną bibliotekę statyczną zbudowaną z Enable C++ Exceptions ustawioną na Nie (nie określono flagi). Jakie są konsekwencje wywoływania tego kodu z kodu zbudowanego z włączonymi wyjątkami C++ (/EHa)? Jeśli Structured Exception jest generowany z biblioteki, czy funkcja udostępniana _set_se_translatorowi przez główną aplikację będzie rzetelnie wywoływana? (Moje eksperymenty pokazują, że tak się stanie, ale zastanawiam się, czy to jest zdefiniowane zachowanie).

Czy są inne kwestie związane z mieszaniem modeli wyjątków od /EH?

Answer 1

Wywołanie w kod, który nie ma włączonych wyjątków, nie powinien powodować żadnych problemów - nie różni się to od wywoływania zewnętrznej funkcji C lub czegoś podobnego.

Wywołanie z kodem, który nie ma wyjątków włączone (do wyjątków kodzie obsługującym) prawdopodobnie nie będzie zawierać poprawną semantykę odwijania stosu wyjątku w kodzie wyłączona, co oznacza, że ​​będziesz łamanie niezmienników tego kodeksu, chyba że został specjalnie zaprojektowany do pracy z wyjątkami. (Na przykład niektóre biblioteki (na przykład ANTLR) przydzielają całą pamięć w bloku i mają kod użytkownika uwalniający wszystko na raz, zezwalając na wyjątki, które mogą być używane bez przecieków, nawet jeśli same nie stosują wyjątków).

Raymond Chen ma dość artykuł o wnętrznościach, w jaki sposób obsługa wyjątków C++ działa na MSVC++. Krótko mówiąc, jest zbudowany na Windows SEH. Dlatego powinien zachowywać się podobnie do tego, co się stanie, jeśli rzucisz wyjątek SEH w np. Kod C (Jednak nie zweryfikujesz ten sam)

Answer 2

Według MSDN następnie jeden jest dozwolone mieszać /EHa and /EHsc:

dwóch modeli obsługi wyjątków, synchronicznych i asynchronicznych, są w pełni kompatybilne i mogą być mieszane w tej samej aplikacji.

Ale nie wydaje się wyjątek od tej reguły, a to przy przejściu wyjątki od niekontrolowana (/ EHsc) do managed (/clr). Zarządzane kody przechwytują wszystkie wyjątki przy użyciu strukturalnej obsługi wyjątków (SEH), co powoduje, że przy odwijaniu stosu jest unmanaged destructors not to be called. Istnieją różne sposoby obejścia tego problemu:

1. Zmień kod niezarządzany na adres/EHa zamiast/EHsc. Ma to tę wadę, że złapanie (...) w niezarządzanym kodzie nagle złapie naruszenia dostępu i inne szalone rzeczy.

2. Utwórz blok try-catch w kodzie niezarządzanym i upewnij się, że nie ma wyjątków między niezarządzanym światem a zarządzanym światem.

   2.1. Możliwe środkowe drogi to zapewnienie, że żadne destruktory nie będą wywoływane podczas przekazywania wyjątku z niezarządzanego do zarządzanego świata. W kodzie niezarządzanym utwórz opakowanie próbne, a następnie w bloku catch ponownie wyrzuć wyjątek do zarządzanego świata.