Blazor server InputFile not properly handling exceptions

[Davey-Rodriguez]

Describe the bug

When using the <InputFile> and binding the OnChange="@LoadFiles" method, if the method throws an exception it will not break the Blazor server circuit or log the error to the server's console. The error will be logged to the browser's console and the app will continue to function as if nothing happened. This behavior seems to differ from everything else I have seen when handling exceptions in Blazor Server.

For example, when I use a normal button and bind the @onclick="() => LoadFiles(null) method, an exceptions will be logged to the server's console and the Blazor Server circuit will be broken. Any reason this isn't the same behavior when using <InputFile>? This causes things to seemingly fail silently especially in async methods .

To Reproduce

<InputFile OnChange="@LoadFiles" />
<button @onclick="() => LoadFiles(null)">Blow up</button>

@code {
    private void LoadFiles(InputFileChangeEventArgs e) {
        throw new Exception();
    }
}

Further technical details

• ASP.NET Core version: 6
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version: VS 2022 64-bit Version 17.0.1
• Include the output of dotnet --info:

dotnet --info Output

.NET SDK (reflecting any global.json):
 Version:   6.0.100
 Commit:    9e8b04bbff

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19042
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.100\

Host (useful for support):
  Version: 6.0.0
  Commit:  4822e3c3aa

.NET SDKs installed:
  3.0.100 [C:\Program Files\dotnet\sdk]
  5.0.200 [C:\Program Files\dotnet\sdk]
  6.0.100-preview.6.21355.2 [C:\Program Files\dotnet\sdk]
  6.0.100 [C:\Program Files\dotnet\sdk]

[TanayParikh]

Thanks for contacting us @KrazyTako, looks like this may be a duplicate of #38502.

[SteveSandersonMS]

We think this is because InputFile triggers the OnChange call via JS interop, which in general means that the JS-side code is responsible for handling any errors. In this case since there's no application JS code that calls this, we probably should treat it as a fatal exception. It should be relatively straightforwards to change this, though is arguably a breaking change.

[TanayParikh]

We'll want to await the InvokeAsync and wrap with a try/catch. In the case of an exception, we'll need to treat it as a fatal exception & crush the circuit.

aspnetcore/src/Components/Web/src/Forms/InputFile.cs

Line 110 in bf9225b

return OnChange.InvokeAsync(new InputFileChangeEventArgs(files));

[TanayParikh]

Looked into this some more, it may not be as straightforward a solution as I previously thought. The main issue is the InputFile.cs is defined in Microsoft.AspNetCore.Components.Forms and is platform agnostic (server vs. wasm). So there isn't a clear way to force-crush the circuit as we do elsewhere (ex. via UnhandledException in CircuitHost).

aspnetcore/src/Components/Server/src/Circuits/CircuitHost.cs

Lines 64 to 68 in bf9225b

	// An unhandled exception from the renderer is always fatal because it came from user code.
	Renderer.UnhandledException += ReportAndInvoke_UnhandledException;
	Renderer.UnhandledSynchronizationException += SynchronizationContext_UnhandledException;
	JSRuntime.UnhandledException += ReportAndInvoke_UnhandledException;

This may require some design on how we wish to handle this. One proposal is to implement an OnError event handler in addition to the existing OnChange handler. Then if OnChange fails here:

aspnetcore/src/Components/Web/src/Forms/InputFile.cs

Line 110 in bf9225b

return OnChange.InvokeAsync(new InputFileChangeEventArgs(files));

Then we could redirect to the OnError handler.