Implement Dispatcher.UnhandledException and Dispatcher.UnhandledExceptionFilter #14432
Conversation
…xception to be swallowed
…it in SyncContext
|
You can test this PR using the following package version. |
| } | ||
| else | ||
| { | ||
| InvokeAsyncImpl(new SendOrPostCallbackDispatcherOperation(this, priority, action, arg, true), |
There was a problem hiding this comment.
Send implies a synchronous wait, InvokeAsyncImpl won't wait for the operation to be completed.
src/Avalonia.Controls/TopLevel.cs
Outdated
|
|
||
| _inputManager?.ProcessInput(e); | ||
| topLevel._inputManager?.ProcessInput(e); | ||
| }, (this, e), DispatcherPriority.Send); |
There was a problem hiding this comment.
I'm not sure if we should be changing the current DispatcherPriority to Send, it will affect the SynchronizationContext used for the callback.
There was a problem hiding this comment.
That's what WPF does.
Also, with other priorities dispatcher operation won't be executed immediately.
There was a problem hiding this comment.
There was a problem hiding this comment.
Yes, but it will make
await Foo();
window.Close();
to cause native crashes on macOS in certain code paths (render being forced via [NSView updateLayer]) again.
It was one of the reasons why we've changed our default dispatcher priority to be lower than Render.
Not sure how to proceed here, it's technically a behavior change.
There was a problem hiding this comment.
@kekekeks changed the way how Dispatcher.Send works. Also fixing behavioral change my previous changes introduced.
Both AvaloniaSynchronizationContext.Send and Dispatcher.Send shouldn't change current sync context, when we already on the dispatcher thread.
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
|
You can test this PR using the following package version. |
How was the solution implemented (if it's not obvious)?
Implements both Dispatcher.UnhandledException and Dispatcher.UnhandledExceptionFilter, by copypasting error handling logic from WPF. And adjusting DispatcherOperation logic in Avalonia.
The same as in WPF, this feature is not recommended for general use. Major nuances:
Dispatcher.Invoke/InvokeAsyncevents bypass Dispatcher.UnhandledException completely. General rule of thumb - if method can return exception (by throwing it or as part of DispatcherOperation object), then UnhandledException is not executed (as these exceptions can be in fact handled by the used). The same behavior work in WPF (except old method based on LegacyInvokeImpl, but that's where WPF is even more broken).Checklist
Breaking changes
None
Fixed issues
Closes #13476
Fixes #13393
Fixes #8418