Error boundaries are not catching all exceptions
See original GitHub issueIs there an existing issue for this?
- I have searched the existing issues
Describe the bug
When method is using async void
construction Error boundaries are not able to catch exception inside such method and application will crash.
For example: If I have a component wrapped with error boundaries and it has such methods inside it, so this code will lead to a crash.
protected override async Task OnAfterRenderAsync(bool firstRender)
{
await base.OnAfterRenderAsync(firstRender);
ThrowError();
}
private async void ThrowError()
{
await Task.Delay(100);
throw new Exception("Some exception");
}
Is there a way how to prevent app from crashing in this case?
Can you add something, so error boundaries will be able to catch exceptions in async void
methods?
Expected Behavior
Crash not happening with error boundaries even if async void
method had thrown an exception.
Steps To Reproduce
No response
Exceptions (if any)
Error: System.Exception: Some exception at TestNet6.Components.ComponentWithError.ThrowError() in C:\Data\Blazor\TestNet6\TestNet6\Components\ComponentWithError.razor:line 47 at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_0(Object state) at Microsoft.AspNetCore.Components.Rendering.RendererSynchronizationContext.ExecuteSynchronously(TaskCompletionSource`1 completion, SendOrPostCallback d, Object state) at Microsoft.AspNetCore.Components.Rendering.RendererSynchronizationContext.<>c.<.cctor>b__23_0(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) — End of stack trace from previous location — at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at Microsoft.AspNetCore.Components.Rendering.RendererSynchronizationContext.ExecuteBackground(WorkItem item)
.NET Version
6.0.101
Anything else?
No response
Issue Analytics
- State:
- Created 2 years ago
- Comments:8 (7 by maintainers)
Top GitHub Comments
Is the sync context section the right spot then, or should I create a section for this remark?
I wouldn’t mention the synchronization context, just mention that the framework doesn’t track void returning async methods and as a result exceptions will not be caught in those scenarios and they need to change the return type to return a Task