Open cameronwhite opened 1 year ago
This probably affects regular callbacks, too.
yep, I think it probably applies for any delegates that get passed into and then called by native code
Fixed for signal callbacks in #861
One thing that I noticed in #862 is that return types (or out parameters) add some complexity for exception handling in callbacks. Since the exception is swallowed and then control returns to the native function, the native code needs to have a valid return value since it's proceeding as usual. So, we probably need to set the return value to some default value if the managed callback has an unhandled exception
In GtkSharp, it looks like they just did this for bool return types (and void, of course), but if there was any other return type, or an out parameter, they just gave up and treated the unhandled exception as a fatal error and terminated.
In GtkSharp, the bindings caught any unhandled exceptions from callbacks (e.g. https://github.com/GtkSharp/GtkSharp/blob/c6a2696d2288375c43486ba7ae2018ed027b16c5/Source/Libs/GLibSharp/SignalClosure.cs#L181 and https://github.com/GtkSharp/GtkSharp/blob/develop/Source/Libs/GLibSharp/ExceptionManager.cs) and raised an event that allowed the application to log or display errors (Example from Pinta: https://github.com/PintaProject/Pinta/blob/5428fa04d3ca4562980e702b1bc568f9ec0b1bb7/Pinta/Main.cs#L137)
Otherwise, it seems like these unhandled exceptions will just terminate the program once they hit the native code boundary that invoked the delegate, so an outer try/catch block around
application.Run()
doesn't seem to workExample program: