Skip to content
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 support for error boundaries in Blazor #26953

Closed
Tracked by #27883
captainsafia opened this issue Oct 15, 2020 · 6 comments
Closed
Tracked by #27883

Add support for error boundaries in Blazor #26953

captainsafia opened this issue Oct 15, 2020 · 6 comments
Assignees
Labels
affected-medium This issue impacts approximately half of our customers area-blazor Includes: Blazor, Razor Components Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one Priority:2 Work that is important, but not critical for the release severity-blocking This label is used by an internal tool User Story A single user-facing feature. Can be grouped under an epic.
Milestone

Comments

@captainsafia
Copy link
Member

captainsafia commented Oct 15, 2020

Summary

This proposes adding an error boundaries feature to Blazor, as inspired by the implementation in React. This feature would allow developers to implement logic on individual components to capture any excpetions, log, display a fallback UI, send telemetry, etc.

This feature was proposed in #13452 but I'm pulling it out into a separate issue to be more precise about the proposed solution.

Motivation

A meaningfully complex Blazor app will contain numerous components, both first-party and third-party. There's no way to guarantee that all exception cases will be handled in a component. There's also no way to indicate that even though an unhandled exception occurred in one part of the app, that the entire app is not compromised.

Goals

  • Allow users to provide fallback UIs for select component subtrees in the event that there is an exception there
  • Allow users to build apps with cleaner fallback experiences in the event of unexpected UIs
  • Give users more fine-grained control over how failures are handled in the app

Non-goals

  • Implement any kind of global exception handling in Blazor (we already have ILogger for logging, and beyond that, truly unhandled exceptions mean the app is in an undefined state which is unsafe to continue)
  • Add more sophisticated exception handling to the components in Blazor (besides the APIs needed to build this feature)
@captainsafia captainsafia added enhancement This issue represents an ask for new feature or an enhancement to an existing one area-blazor Includes: Blazor, Razor Components labels Oct 15, 2020
@captainsafia captainsafia added this to the Next sprint planning milestone Oct 15, 2020
@ghost
Copy link

ghost commented Oct 15, 2020

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@captainsafia captainsafia added affected-medium This issue impacts approximately half of our customers severity-blocking This label is used by an internal tool labels Oct 20, 2020
@gulbanana
Copy link

gulbanana commented Oct 23, 2020

This would be wonderful. At a motivating use case, here’s a situation I can’t currently handle in Blazor:

<div>
    <MyComponent />
    <ThirdPartyComponent Attr=“null” />
</div>

where ThirdPartyComponent.razor contains something like this:

@code {
    [Parameter] public string Attr { get; set; }
}
<p>@Attr.ToLower()</p>

Right now, there’s no way to salvage the render tree and display at least MyComponent, due to the failure to handle errors inside the other Component

@mkArtakMSFT mkArtakMSFT added the User Story A single user-facing feature. Can be grouped under an epic. label Jan 31, 2021
@mkArtakMSFT mkArtakMSFT added the Priority:2 Work that is important, but not critical for the release label Jan 31, 2021
@mrdavidhanson
Copy link

Just adding my $0.02. I would also love to see Blazor have something similar to React's Error Boundaries. From my perspective, it is difficult to consider Blazor as being production ready until it has this type of a feature. There is no way that a single small unhandled exception in a developer's code, or worse - a third-party component's code, should cripple an entire application unless a developer wishes for that to happen. When an MVC app or WebForms app has an isolated exception, it does not kill the application. But Blazor? Game over. If using Blazor Server, the user's SignalR connection is nuked and state is lost. Not very fun being a developer and having to explain this to management and end users. If Blazor had something like a React Error Boundary, only the faulty component could be disabled showing a user-friendly error message and the rest of the application could continue to function as expected.

I see this issue currently has a Priority Level of 2. Personally, I would make it even higher priority. Application stability is a fundamental requirement.

@mrlife
Copy link
Contributor

mrlife commented Feb 15, 2021

@SteveSandersonMS Are you thinking that the "global" aspect of #13452 could be handled by the user adding the solution in this issue to a sufficiently high component in the hierarchy, e.g. App.razor?

@SteveSandersonMS
Copy link
Member

Yes, if you find it useful to put in error handling logic there.

@SteveSandersonMS
Copy link
Member

Done in #30874

@ghost ghost added Done This issue has been fixed and removed Working labels Apr 8, 2021
@ghost ghost locked as resolved and limited conversation to collaborators May 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affected-medium This issue impacts approximately half of our customers area-blazor Includes: Blazor, Razor Components Done This issue has been fixed enhancement This issue represents an ask for new feature or an enhancement to an existing one Priority:2 Work that is important, but not critical for the release severity-blocking This label is used by an internal tool User Story A single user-facing feature. Can be grouped under an epic.
Projects
None yet
Development

No branches or pull requests

6 participants