MobileBlazorBindings
MobileBlazorBindings copied to clipboard
dotnet
Allow customizing default unhandled exception handler
I would like to be able to override default error screen behavior - probably by implementing IBlazorErrorHandler (not sure why is that in Microsoft.MobileBlazorBindings.WebView project now), and providing it somewhere.
In Hybrid Blazor? You can by binding an IBlazorErrorHandler implementation to the ErrorHandler parameter on the BlazorWebView component:
https://github.com/xamarin/MobileBlazorBindings/blob/master/src/Microsoft.MobileBlazorBindings/Elements/BlazorWebView.cs#L30
And that totally makes sense! I'll tag @Eilon to look at this. It seems trivial to move IBlazorErrorHandler to Microsoft.MobileBlazorBindings and find a way to expose it to the outside world (Either through the DI container or on a registration method during composition.
We can't move IBlazorErrorHandler to Microsoft.MobileBlazorBindings, because that will introduce circular dependency. While we can easily move it to Microsoft.MobileBlazorBindings.Core instead, I would prefer to move all hybrid related staff to Microsoft.MobileBlazorBindings.WebView, and remove that dependency from Microsoft.MobileBlazorBindings (so that I wouldn't have to import all Web related staff if i need native components only - currently it clutters IntelliSense a lot.
Hmm definitely some interesting ideas here, will have to think about the layering. Much of the layering here is "for convenience" so that 99.99% of projects can reference 1 NuGet package and it pulls in everything you need. Of course, it's always going to be more than you need because no one needs everything. At some future point we'll definitely reconsider the overall layering so that projects can be leaner. But app trimming is probably the best solution to this anyway because that will do more than we ever could solve with layering.
But for error handling I'm sure we can come up with something good.
Can you share some info on what you would do in the error handler? That will help ensure the design we come up with is suitable.
App trimming will help with app size, but not with cluttered IntelliSense.
I'd like to handle some custom ApiExceptions in different way (probably showing some alert with more or less friendly message), plus I'd like to avoid showing exception details in non-development builds.
So you want to be able to "handle" certain errors, and not just show a different (nicer) error message? Right now once the error gets to the error handler the app is considered "dead" but I think we can easily change that.
@jspuij Thanks for the steer on how to set the custom error handler. I'd expected it to be work automatically based on a custom service registration with the DI container. When I registered a custom IBlazorErrorHandler implementation into DI and it wasn't used, I was slightly confused!
I've updated Main.razor in my solution to accept an injected variable of type IBlazorErrorHandler, and pass that on to the BlazorWebView via its ErrorHandler parameter.
I wonder if the code generated by the Hybrid App template should contain this by default, so that people don't need to go searching for why their custom implementation is not being used as they might have expected.
I can see why the DI-based approach was not used in the code as it stands, since the BlazorWebView class currently has a static constructor to initialise it just one time. However, maybe that is something that could be changed to make it more obvious how to customise the behaviour using standard DI registration practices? At the moment, there are a couple of steps needed to be able to output the details of an exception to ILogger, which I'd expected to happen automatically (but doesn't, as far as I can tell.)
@TheCakeMonster we could try to make this work. For now it's just an area where we put in a quick feature to make some really-bad scenarios be less-bad, but it's still not great! We'll have to think about this one a bit to come up with a reasonable solution.