Proper handling of .NET exceptions

UPDATE: My problems are solved. For a quick outline of my problems and their solutions, see my last comment.

---

AFAIK, the current behavior when a .NET exception is caught, is to simply raise a Win32 exception with code 0xe0434352. It is hard to know the details of the exception, which makes debugging very difficult.

I’m currently having a hard time debugging a C# shim which is expected to be called from Python. It could be a lot more handy if I could know the details of the exceptions.

My story:

I was unaware that .NET assemblies should be put in the same directory as the executable file (putting them in the current directory or %Path% did not work). So I always get a 0xe0434352 whenever I call any of the [DllExport] functions. I tried hard to rearrange my code and see if anything changes, but without success. Finally, by using .NET reflection, I realized that I should try to add the current directory to the .NET search path, using the instructions on Stack Overflow.

Currently, I’m facing another problem, that I’m unable to call a [DllExport] method from another [DllExport] method (I realized that by changing my code). For example, the following code did not work:

[DllExport]
public static int GetWidth() { ... }

// Calling the following method results in 0xe0434352
[DllExport]
public static void ProcessImage()
{
  int width = GetWidth();
  ...
}

If there were any way to catch these exceptions, it could be really helpful.

Anyway, thank you very much for making this library, it is really amazing when it works.

[chen-456]

Yes. Let me clarify for readers in the future, all the problems I have met were:

1. Being unable to load .NET assemblies / DLLs from outside the program directory (even if %PATH% was set)
2. Being unable to call [DllExport] methods from [DllExport] methods
3. The Python console not printing any detailed information upon such .NET exceptions (it just says Windows Error 0xe0434352)

Finally, my solutions are to:

1. Write another .NET DLL that injects to the assembly search path (also try pre-processing with ILMerge, as stated in the Wiki) (related: #156)
2. Avoid such manners and add another layer of indirection (related: #94)
3. Use Visual Studio debugger to catch those .NET exceptions, and it will show their details (as in my last comment)

No problems about SEH / access violations, I believe.

At last, thank you for all your hard work!

[3F]

Well, I see 😃 mixed problems. My thoughts, as I said, were about seh and some memory violation or like, for the term of “these” (because of src).

Still a duplicate, thus please read all related issues above. Thanks for clarifying information to our users!