-
Notifications
You must be signed in to change notification settings - Fork 27
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
Add an event for unhandled exceptions from delegates invoked by native code #860
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The concept looks good to me. Please see my comments.
I wonder if it should be an event at all? Is it useful to have more than one subscriber? If not perhaps a simple callback should be used instead of an event? Something similar to: or even better additionally something like: which could allow code like: GLib.UnhandledException.SetHandler<NullReferenceException>(..);
GLib.UnhandledException.SetHandler<OutOfMemoryException>(..);
GLib.UnhandledException.SetHandler(..); // all other exceptions Edit: |
…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
057e9ac
to
7489f8b
Compare
Thanks! Updated with those changes. That's a good question about it being an event .. this was mostly following GtkSharp's GLib.ExceptionManager, which I think in turn was probably following In Pinta we only ever had one handler though, which pops open a message dialog and prints some info to the console |
I wonder if the generic handler approach enables this scenario:
Actually what happens if an exception is thrown in an event handler if it is purely managed? The runtime stops, too? Then this would be no help as the user is responsible to add a try/catch block in the handler themselves. |
Replaced by #861 |
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.
Currently this only supports signal handlers for testing purposes, but would need to be extended to the other callback types.
Bug: #845