-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support dealing with unhandled exceptions from signal callbacks #845
Comments
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 |
…e code These unhandled exceptions would otherwise immediately terminate the program once they reach the native code boundary. This event lets applications do any logging / message dialogs etc and decide whether they want to terminate the program or attempt to continue. Bug: #845
…e code These unhandled exceptions would otherwise immediately terminate the program once they reach the native code boundary. This event lets applications do any logging / message dialogs etc and decide whether they want to terminate the program or attempt to continue. Bug: #845
Fixed for signal callbacks in #861 |
This is good to have in general, but is also needed for #845 where we want to test exception handling for callbacks Callbacks with `notified` scope are the only type that currently has full support for generating public bindings
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. 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:
The text was updated successfully, but these errors were encountered: