Различия в поведении при обработке исключений в /CLR
Основные понятия использования управляемых исключений рассматривают обработку исключений в управляемых приложениях. В этом разделе подробно рассматриваются различия от стандартного поведения обработки исключений и некоторые ограничения. Дополнительные сведения см. в разделе "Функция _set_se_translator".
Прыжки из блока наконец
В собственном коде C/C++ переход из блока __finally с помощью структурированной обработки исключений (SEH) допускается, хотя он создает предупреждение. В разделе /clr переход из блока, наконец , приводит к ошибке:
// clr_exception_handling_4.cpp
// compile with: /clr
int main() {
try {}
finally {
return 0; // also fails with goto, break, continue
}
} // C3276
Создание исключений в фильтре исключений
При возникновении исключения во время обработки фильтра исключений в управляемом коде исключение перехватится и обрабатывается так, как если фильтр возвращает значение 0.
Это отличается от поведения в машинном коде, в котором возникает вложенное исключение, поле ExceptionRecord в структуре EXCEPTION_RECORD (как возвращается GetExceptionInformation), а поле ExceptionFlags задает бит 0x10. В следующем примере показано различие в поведении:
// clr_exception_handling_5.cpp
#include <windows.h>
#include <stdio.h>
#include <assert.h>
#ifndef false
#define false 0
#endif
int *p;
int filter(PEXCEPTION_POINTERS ExceptionPointers) {
PEXCEPTION_RECORD ExceptionRecord =
ExceptionPointers->ExceptionRecord;
if ((ExceptionRecord->ExceptionFlags & 0x10) == 0) {
// not a nested exception, throw one
*p = 0; // throw another AV
}
else {
printf("Caught a nested exception\n");
return 1;
}
assert(false);
return 0;
}
void f(void) {
__try {
*p = 0; // throw an AV
}
__except(filter(GetExceptionInformation())) {
printf_s("We should execute this handler if "
"compiled to native\n");
}
}
int main() {
__try {
f();
}
__except(1) {
printf_s("The handler in main caught the "
"exception\n");
}
}
Выходные данные
Caught a nested exception
We should execute this handler if compiled to native
Отсоединенные повторы
/clr не поддерживает повторное увеличение исключения за пределами обработчика catch (известного как разъединение повторного выполнения). Исключения этого типа рассматриваются как стандартное повторное выполнение C++ . Если при наличии активного управляемого исключения возникает разъединение повторного выполнения, исключение упаковывается в виде исключения C++, а затем повторно выполняется повторно. Исключения этого типа можно поймать только как исключение типа SEHException.
В следующем примере показано повторное изменение управляемого исключения в виде исключения C++:
// clr_exception_handling_6.cpp
// compile with: /clr
using namespace System;
#include <assert.h>
#include <stdio.h>
void rethrow( void ) {
// This rethrow is a dissasociated rethrow.
// The exception would be masked as SEHException.
throw;
}
int main() {
try {
try {
throw gcnew ApplicationException;
}
catch ( ApplicationException^ ) {
rethrow();
// If the call to rethrow() is replaced with
// a throw statement within the catch handler,
// the rethrow would be a managed rethrow and
// the exception type would remain
// System::ApplicationException
}
}
catch ( ApplicationException^ ) {
assert( false );
// This will not be executed since the exception
// will be masked as SEHException.
}
catch ( Runtime::InteropServices::SEHException^ ) {
printf_s("caught an SEH Exception\n" );
}
}
Выходные данные
caught an SEH Exception
Фильтры исключений и EXCEPTION_CONTINUE_EXECUTION
Если фильтр возвращается EXCEPTION_CONTINUE_EXECUTION в управляемом приложении, он обрабатывается как возвращенный фильтр EXCEPTION_CONTINUE_SEARCH. Дополнительные сведения об этих константах см . в инструкции try-except.
В следующем примере показано следующее различие:
// clr_exception_handling_7.cpp
#include <windows.h>
#include <stdio.h>
#include <assert.h>
int main() {
int Counter = 0;
__try {
__try {
Counter -= 1;
RaiseException (0xe0000000|'seh',
0, 0, 0);
Counter -= 2;
}
__except (Counter) {
// Counter is negative,
// indicating "CONTINUE EXECUTE"
Counter -= 1;
}
}
__except(1) {
Counter -= 100;
}
printf_s("Counter=%d\n", Counter);
}
Выходные данные
Counter=-3
Функция _set_se_translator
Функция переводчика, заданная вызовом _set_se_translator, влияет только на перехваты в неуправляемом коде. В следующем примере показано это ограничение:
// clr_exception_handling_8.cpp
// compile with: /clr /EHa
#include <iostream>
#include <windows.h>
#include <eh.h>
#pragma warning (disable: 4101)
using namespace std;
using namespace System;
#define MYEXCEPTION_CODE 0xe0000101
class CMyException {
public:
unsigned int m_ErrorCode;
EXCEPTION_POINTERS * m_pExp;
CMyException() : m_ErrorCode( 0 ), m_pExp( NULL ) {}
CMyException( unsigned int i, EXCEPTION_POINTERS * pExp )
: m_ErrorCode( i ), m_pExp( pExp ) {}
CMyException( CMyException& c ) : m_ErrorCode( c.m_ErrorCode ),
m_pExp( c.m_pExp ) {}
friend ostream& operator <<
( ostream& out, const CMyException& inst ) {
return out << "CMyException[\n" <<
"Error Code: " << inst.m_ErrorCode << "]";
}
};
#pragma unmanaged
void my_trans_func( unsigned int u, PEXCEPTION_POINTERS pExp ) {
cout << "In my_trans_func.\n";
throw CMyException( u, pExp );
}
#pragma managed
void managed_func() {
try {
RaiseException( MYEXCEPTION_CODE, 0, 0, 0 );
}
catch ( CMyException x ) {}
catch ( ... ) {
printf_s("This is invoked since "
"_set_se_translator is not "
"supported when /clr is used\n" );
}
}
#pragma unmanaged
void unmanaged_func() {
try {
RaiseException( MYEXCEPTION_CODE,
0, 0, 0 );
}
catch ( CMyException x ) {
printf("Caught an SEH exception with "
"exception code: %x\n", x.m_ErrorCode );
}
catch ( ... ) {}
}
// #pragma managed
int main( int argc, char ** argv ) {
_set_se_translator( my_trans_func );
// It does not matter whether the translator function
// is registered in managed or unmanaged code
managed_func();
unmanaged_func();
}
Выходные данные
This is invoked since _set_se_translator is not supported when /clr is used
In my_trans_func.
Caught an SEH exception with exception code: e0000101
См. также
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по