Последствия создания исключения в делегате неуправляемого обратного вызова

Question

Каковы последствия или непредвиденные последствия создания исключения внутри делегата, который используется во время неуправляемого обратного вызова?Вот моя ситуация:

Неуправляемый C:

int return_callback_val(int (*callback)(void))
{
  return callback();
}

Управляемый C #:

[DllImport("MyDll.dll")]
static extern int return_callback_val(IntPtr callback);

[UnmanagedFunctionPointer(CallingConvention.Cdecl)]
delegate int CallbackDelegate();

int Callback()
{
  throw new Exception();
}

void Main()
{
  CallbackDelegate delegate = new CallbackDelegate(Callback);
  IntPtr callback = Marshal.GetFunctionPointerForDelegate(delegate);
  int returnedVal = return_callback_val(callback);
}

Answer 1

Собственный код будет бомбить необработанное исключение, и программа завершается.

Если вы действительно хотите обработать это исключение, вам нужно использовать пользовательские __try/__catch ключевые слова в собственном коде. Что довольно бесполезно, все детали управляемого исключения потеряны. Единственной отличительной характеристикой является код исключения 0xe0434f4d. Поскольку вы не можете точно знать, что пошло не так, вы также не можете надежно восстановить состояние программы. Лучше не ловить это. Или лучше не бросай его.

Answer 2

Я думаю, что правильный способ сказать COM-объекту, что у вас есть исключение, это просто вернуть HRESULT.E_FAIL.

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