In a Blazor Web App, customize the experience in theMainLayout component. Because theEnvironment Tag Helper (for example,<environment include="Production">...</environment>) isn't supported in Razor components, the following example injectsIHostEnvironment to configure error messages for different environments.

At the top ofMainLayout.razor:

@inject IHostEnvironment HostEnvironment

Create or modify the Blazor error UI markup:

<div data-nosnippet>    @if (HostEnvironment.IsProduction())    {        <span>An error has occurred.</span>    }    else    {        <span>An unhandled exception occurred.</span>    }    <a href="">Reload</a>    <a>🗙</a></div>

In a Blazor Server app, customize the experience in thePages/_Host.cshtml file. The following example uses theEnvironment Tag Helper to configure error messages for different environments.

In a Blazor Server app, customize the experience in thePages/_Layout.cshtml file. The following example uses theEnvironment Tag Helper to configure error messages for different environments.

In a Blazor Server app, customize the experience in thePages/_Host.cshtml file. The following example uses theEnvironment Tag Helper to configure error messages for different environments.

Create or modify the Blazor error UI markup:

<div data-nosnippet>    <environment include="Staging,Production">        An error has occurred.    </environment>    <environment include="Development">        An unhandled exception occurred.    </environment>    <a href="">Reload</a>    <a>🗙</a></div>

Theblazor-error-ui element is normally hidden due to the presence of thedisplay: none style of theblazor-error-ui CSS class in the app's auto-generated stylesheet. When an error occurs, the framework appliesdisplay: block to the element.

Theblazor-error-ui element is normally hidden due to the presence of thedisplay: none style of theblazor-error-ui CSS class in the site's stylesheet in thewwwroot/css folder. When an error occurs, the framework appliesdisplay: block to the element.

This section applies to Blazor Web Apps operating over a circuit.

This section applies to Blazor Server apps.

Warning

Always avoid exposing error information to clients on the Internet, which is a security risk.

Detailed errors for Razor component server-side rendering

This section applies to Blazor Web Apps.

Use theRazorComponentsServiceOptions.DetailedErrors option to control producing detailed information on errors for Razor component server-side rendering. The default value isfalse.

The following example enables detailed errors:

builder.Services.AddRazorComponents(options =>     options.DetailedErrors = builder.Environment.IsDevelopment());

For approaches to handling exceptions globally, see the following sections:

• Error boundaries: Applies to all Blazor apps.
• Alternative global exception handling: Applies to Blazor Server, Blazor WebAssembly, and Blazor Web Apps (8.0 or later) that adopt a global interactive render mode.

Error boundaries

Error boundaries provide a convenient approach for handling exceptions. TheErrorBoundary component:

• Renders its child content when an error hasn't occurred.
• Renders error UI when an unhandled exception is thrown by any component within the error boundary.

To define an error boundary, use theErrorBoundary component to wrap one or more other components. The error boundary manages unhandled exceptions thrown by the components that it wraps.

<ErrorBoundary>    ...</ErrorBoundary>

To implement an error boundary in a global fashion, add the boundary around the body content of the app's main layout.

InMainLayout.razor:

<article>    <ErrorBoundary>        @Body    </ErrorBoundary></article>

In Blazor Web Apps with the error boundary only applied to a staticMainLayout component, the boundary is only active during static server-side rendering (static SSR). The boundary doesn't activate just because a component further down the component hierarchy is interactive.

An interactive render mode can't be applied to theMainLayout component because the component'sBody parameter is aRenderFragment delegate, which is arbitrary code and can't be serialized. To enable interactivity broadly for theMainLayout component and the rest of the components further down the component hierarchy, the app must adopt a global interactive render mode by applying the interactive render mode to theHeadOutlet andRoutes component instances in the app's root component, which is typically theApp component. The following example adopts the Interactive Server (InteractiveServer) render mode globally.

InComponents/App.razor:

<HeadOutlet @rendermode="InteractiveServer" />...<Routes @rendermode="InteractiveServer" />

If you prefer not to enable global interactivity, place the error boundary farther down the component hierarchy. The important concepts to keep in mind are that wherever the error boundary is placed:

• If the component where the error boundary is placed isn't interactive, the error boundary is only capable of activating on the server during static SSR. For example, the boundary can activate when an error is thrown in a component lifecycle method but not for an event triggered by user interactivity within the component, such as an error thrown by a button click handler.
• If the component where the error boundary is placed is interactive, the error boundary is capable of activating for interactive components that it wraps.

Consider the following example, where an exception thrown by an embedded counter component is caught by an error boundary in theHome component, which adopts an interactive render mode.

EmbeddedCounter.razor:

<h1>Embedded Counter</h1><p role="status">Current count: @currentCount</p><button @onclick="IncrementCount">Click me</button>@code {    private int currentCount = 0;    private void IncrementCount()    {        currentCount++;        if (currentCount > 5)        {            throw new InvalidOperationException("Current count is too big!");        }    }}

Home.razor:

@page "/"@rendermode InteractiveServer<PageTitle>Home</PageTitle><h1>Home</h1><ErrorBoundary>    <EmbeddedCounter /></ErrorBoundary>

Consider the following example, where an exception thrown by an embedded counter component is caught by an error boundary in theHome component.

EmbeddedCounter.razor:

<h1>Embedded Counter</h1><p role="status">Current count: @currentCount</p><button @onclick="IncrementCount">Click me</button>@code {    private int currentCount = 0;    private void IncrementCount()    {        currentCount++;        if (currentCount > 5)        {            throw new InvalidOperationException("Current count is too big!");        }    }}

Home.razor:

@page "/"<PageTitle>Home</PageTitle><h1>Home</h1><ErrorBoundary>    <EmbeddedCounter /></ErrorBoundary>

If the unhandled exception is thrown for acurrentCount over five:

• The error is logged normally (System.InvalidOperationException: Current count is too big!).
• The exception is handled by the error boundary.
• The default error UI is rendered by the error boundary.

TheErrorBoundary component renders an empty<div> element using theblazor-error-boundary CSS class for its error content. The colors, text, and icon for the default UI are defined in the app's stylesheet in thewwwroot folder, so you're free to customize the error UI.

To change the default error content:

• Wrap the components of the error boundary in theChildContent property.
• Set theErrorContent property to the error content.

The following example wraps theEmbeddedCounter component and supplies custom error content:

<ErrorBoundary>    <ChildContent>        <EmbeddedCounter />    </ChildContent>    <ErrorContent>        <p>😈 A rotten gremlin got us. Sorry!</p>    </ErrorContent></ErrorBoundary>

For the preceding example, the app's stylesheet presumably includes anerrorUI CSS class to style the content. The error content is rendered from theErrorContent property without a block-level element. A block-level element, such as a division (<div>) or a paragraph (<p>) element, can wrap the error content markup, but it isn't required.

Optionally, use the context (@context) of theErrorContent to obtain error data:

<ErrorContent>    @context.HelpLink</ErrorContent>

TheErrorContent can also name the context. In the following example, the context is namedexception:

<ErrorContent Context="exception">    @exception.HelpLink</ErrorContent>

If the error boundary is defined in the app's layout, the error UI is seen regardless of which page the user navigates to after the error occurs. We recommend narrowly scoping error boundaries in most scenarios. If you broadly scope an error boundary, you can reset it to a non-error state on subsequent page navigation events by calling the error boundary'sRecover method.

InMainLayout.razor:

• Add a field for theErrorBoundary tocapture a reference to it with the@ref attribute directive.
• In theOnParameterSet lifecycle method, you can trigger a recovery on the error boundary withRecover to clear the error when the user navigates to a different component.

...<ErrorBoundary @ref="errorBoundary">    @Body</ErrorBoundary>...@code {    private ErrorBoundary? errorBoundary;    protected override void OnParametersSet()    {        errorBoundary?.Recover();    }}

To avoid the infinite loop where recovering merely rerenders a component that throws the error again, don't callRecover from rendering logic. Only callRecover when:

• The user performs a UI gesture, such as selecting a button to indicate that they want to retry a procedure or when the user navigates to a new component.
• Additional logic that executes also clears the exception. When the component is rerendered, the error doesn't reoccur.

The following example permits the user to recover from the exception with a button:

<ErrorBoundary @ref="errorBoundary">    <ChildContent>        <EmbeddedCounter />    </ChildContent>    <ErrorContent>        <div role="alert">            <p>😈 A rotten gremlin got us. Sorry!</p>            <p>@context.HelpLink</p>            <button @onclick="_ => errorBoundary?.Recover()">                Clear            </button>        </div>    </ErrorContent></ErrorBoundary>@code {    private ErrorBoundary? errorBoundary;}

You can also subclassErrorBoundary for custom processing by overridingOnErrorAsync. The following example merely logs the error, but you can implement any error handling code you wish. You can remove the line that returns aCompletedTask if your code awaits an asynchronous task.

CustomErrorBoundary.razor:

@inherits ErrorBoundary@inject ILogger<CustomErrorBoundary> Logger@if (CurrentException is null){    @ChildContent}else if (ErrorContent is not null){    @ErrorContent(CurrentException)}@code {    protected override Task OnErrorAsync(Exception ex)    {        Logger.LogError(ex, "😈 A rotten gremlin got us. Sorry!");        return Task.CompletedTask;    }}

The preceding example can also be implemented as a class.

CustomErrorBoundary.cs:

using Microsoft.AspNetCore.Components;using Microsoft.AspNetCore.Components.Web;namespace BlazorSample;public class CustomErrorBoundary : ErrorBoundary{    [Inject]    ILogger<CustomErrorBoundary> Logger {  get; set; } = default!;    protected override Task OnErrorAsync(Exception ex)    {        Logger.LogError(ex, "😈 A rotten gremlin got us. Sorry!");        return Task.CompletedTask;    }}

Either of the preceding implementations used in a component:

<CustomErrorBoundary>    ...</CustomErrorBoundary>

Alternative global exception handling

The approach described in this section applies to Blazor Server, Blazor WebAssembly, and Blazor Web Apps that adopt a global interactive render mode (InteractiveServer,InteractiveWebAssembly, orInteractiveAuto). The approach doesn't work with Blazor Web Apps that adopt per-page/component render modes or static server-side rendering (static SSR) because the approach relies on aCascadingValue/CascadingParameter, which don't work across render mode boundaries or with components that adopt static SSR.

An alternative to usingError boundaries (ErrorBoundary) is to pass a custom error component as aCascadingValue to child components. An advantage of using a component over using aninjected service or a custom logger implementation is that a cascaded component can render content and apply CSS styles when an error occurs.

The followingProcessError component example merely logs errors, but methods of the component can process errors in any way required by the app, including through the use of multiple error processing methods.

ProcessError.razor:

@inject ILogger<ProcessError> Logger<CascadingValue Value="this" IsFixed="true">    @ChildContent</CascadingValue>@code {    [Parameter]    public RenderFragment? ChildContent { get; set; }    public void LogError(Exception ex)    {        Logger.LogError("ProcessError.LogError: {Type} Message: {Message}",             ex.GetType(), ex.Message);        // Call StateHasChanged if LogError directly participates in         // rendering. If LogError only logs or records the error,        // there's no need to call StateHasChanged.        //StateHasChanged();    }}

When using this approach in a Blazor Web App, open theRoutes component and wrap theRouter component (<Router>...</Router>) with theProcessError component. This permits theProcessError component to cascade down to any component of the app where theProcessError component is received as aCascadingParameter.

InRoutes.razor:

<ProcessError>    <Router ...>        ...    </Router></ProcessError>

When using this approach in a Blazor Server or Blazor WebAssembly app, open theApp component, wrap theRouter component (<Router>...</Router>) with theProcessError component. This permits theProcessError component to cascade down to any component of the app where theProcessError component is received as aCascadingParameter.

InApp.razor:

<ProcessError>    <Router ...>        ...    </Router></ProcessError>

To process errors in a component:

• Designate theProcessError component as aCascadingParameter in the@code block. In an exampleCounter component in an app based on a Blazor project template, add the followingProcessError property:

  [CascadingParameter]private ProcessError? ProcessError { get; set; }

• Call an error processing method in anycatch block with an appropriate exception type. The exampleProcessError component only offers a singleLogError method, but the error processing component can provide any number of error processing methods to address alternative error processing requirements throughout the app. The followingCounter component@code block example includes theProcessError cascading parameter and traps an exception for logging when the count is greater than five:

  @code {    private int currentCount = 0;    [CascadingParameter]    private ProcessError? ProcessError { get; set; }    private void IncrementCount()    {        try        {            currentCount++;            if (currentCount > 5)            {                throw new InvalidOperationException("Current count is over five!");            }        }        catch (Exception ex)        {            ProcessError?.LogError(ex);        }    }}

The logged error:

fail: {COMPONENT NAMESPACE}.ProcessError[0]
ProcessError.LogError: System.InvalidOperationException Message: Current count is over five!

If theLogError method directly participates in rendering, such as showing a custom error message bar or changing the CSS styles of the rendered elements, callStateHasChanged at the end of theLogError method to rerender the UI.

Because the approaches in this section handle errors with atry-catch statement, an app's SignalR connection between the client and server isn't broken when an error occurs and the circuit remains alive. Other unhandled exceptions remain fatal to a circuit. For more information, see the section onhow a circuit reacts to unhandled exceptions.

An app can use an error processing component as a cascading value to process errors in a centralized way.

The followingProcessError component passes itself as aCascadingValue to child components. The following example merely logs the error, but methods of the component can process errors in any way required by the app, including through the use of multiple error processing methods. An advantage of using a component over using aninjected service or a custom logger implementation is that a cascaded component can render content and apply CSS styles when an error occurs.

ProcessError.razor:

@using Microsoft.Extensions.Logging@inject ILogger<ProcessError> Logger<CascadingValue Value="this" IsFixed="true">    @ChildContent</CascadingValue>@code {    [Parameter]    public RenderFragment ChildContent { get; set; }    public void LogError(Exception ex)    {        Logger.LogError("ProcessError.LogError: {Type} Message: {Message}",             ex.GetType(), ex.Message);    }}

In theApp component, wrap theRouter component with theProcessError component. This permits theProcessError component to cascade down to any component of the app where theProcessError component is received as aCascadingParameter.

App.razor:

<ProcessError>    <Router ...>        ...    </Router></ProcessError>

To process errors in a component:

• Designate theProcessError component as aCascadingParameter in the@code block:

  [CascadingParameter]private ProcessError ProcessError { get; set; }

• Call an error processing method in anycatch block with an appropriate exception type. The exampleProcessError component only offers a singleLogError method, but the error processing component can provide any number of error processing methods to address alternative error processing requirements throughout the app.

  try{    ...}catch (Exception ex){    ProcessError.LogError(ex);}

Using the preceding exampleProcessError component andLogError method, the browser's developer tools console indicates the trapped, logged error:

fail: {COMPONENT NAMESPACE}.Shared.ProcessError[0]
ProcessError.LogError: System.NullReferenceException Message: Object reference not set to an instance of an object.

If theLogError method directly participates in rendering, such as showing a custom error message bar or changing the CSS styles of the rendered elements, callStateHasChanged at the end of theLogError method to rerender the UI.

Because the approaches in this section handle errors with atry-catch statement, a Blazor app's SignalR connection between the client and server isn't broken when an error occurs and the circuit remains alive. Any unhandled exception is fatal to a circuit. For more information, see the section onhow a circuit reacts to unhandled exceptions.

If an unhandled exception occurs, the exception is logged toILogger instances configured in the service container. Blazor apps log console output with the Console Logging Provider. Consider logging to a location on the server (or backend web API for client-side apps) with a provider that manages log size and log rotation. Alternatively, the app can use an Application Performance Management (APM) service, such asAzure Application Insights (Azure Monitor).

During development in a Blazor app operating over a circuit, the app usually sends the full details of exceptions to the browser's console to aid in debugging. In production, detailed errors aren't sent to clients, but an exception's full details are logged on the server.

You must decide which incidents to log and the level of severity of logged incidents. Hostile users might be able to trigger errors deliberately. For example, don't log an incident from an error where an unknownProductId is supplied in the URL of a component that displays product details. Not all errors should be treated as incidents for logging.

For more information, see the following articles:

• ASP.NET Core Blazor logging
• Handle errors in ASP.NET Core‡
• Create web APIs with ASP.NET Core

‡Applies to server-side Blazor apps and other server-side ASP.NET Core apps that are web API backend apps for Blazor. Client-side apps can trap and send error information on the client to a web API, which logs the error information to a persistent logging provider.

If an unhandled exception occurs, the exception is logged toILogger instances configured in the service container. Blazor apps log console output with the Console Logging Provider. Consider logging to a more permanent location on the server by sending error information to a backend web API that uses a logging provider with log size management and log rotation. Alternatively, the backend web API app can use an Application Performance Management (APM) service, such asAzure Application Insights (Azure Monitor)†, to record error information that it receives from clients.

You must decide which incidents to log and the level of severity of logged incidents. Hostile users might be able to trigger errors deliberately. For example, don't log an incident from an error where an unknownProductId is supplied in the URL of a component that displays product details. Not all errors should be treated as incidents for logging.

For more information, see the following articles:

• ASP.NET Core Blazor logging
• Handle errors in ASP.NET Core‡
• Create web APIs with ASP.NET Core

†NativeApplication Insights features to support client-side apps and native Blazor framework support forGoogle Analytics might become available in future releases of these technologies. For more information, seeSupport App Insights in Blazor WASM Client Side (microsoft/ApplicationInsights-dotnet #2143) andWeb analytics and diagnostics (includes links to community implementations) (dotnet/aspnetcore #5461). In the meantime, a client-side app can use theApplication Insights JavaScript SDK withJS interop to log errors directly to Application Insights from a client-side app.

‡Applies to server-side ASP.NET Core apps that are web API backend apps for Blazor apps. Client-side apps trap and send error information to a web API, which logs the error information to a persistent logging provider.

• Component instantiation
• Lifecycle methods
• Rendering logic
• Event handlers
• Component disposal
• JavaScript interop
• Prerendering

• Component instantiation
• Lifecycle methods
• Rendering logic
• Event handlers
• Component disposal
• JavaScript interop
• Prerendering

@page "/product-details/{ProductId:int?}"@inject ILogger<ProductDetails> Logger@inject IProductRepository Product<PageTitle>Product Details</PageTitle><h1>Product Details Example</h1>@if (details != null){    <h2>@details.ProductName</h2>    <p>        @details.Description        <a href="@details.Url">Company Link</a>    </p>    }else if (loadFailed){    <h1>Sorry, we could not load this product due to an error.</h1>}else{    <h1>Loading...</h1>}@code {    private ProductDetail? details;    private bool loadFailed;    [Parameter]    public int ProductId { get; set; }    protected override async Task OnParametersSetAsync()    {        try        {            loadFailed = false;            // Reset details to null to display the loading indicator            details = null;            details = await Product.GetProductByIdAsync(ProductId);        }        catch (Exception ex)        {            loadFailed = true;            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);        }    }    public class ProductDetail    {        public string? ProductName { get; set; }        public string? Description { get; set; }        public string? Url { get; set; }    }    /*    * Register the service in Program.cs:    * using static BlazorSample.Components.Pages.ProductDetails;    * builder.Services.AddScoped<IProductRepository, ProductRepository>();    */    public interface IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id);    }    public class ProductRepository : IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id)        {            return Task.FromResult(                new ProductDetail()                {                    ProductName = "Flowbee ",                    Description = "The Revolutionary Haircutting System You've Come to Love!",                    Url = "https://flowbee.com/"                });        }    }}

@page "/product-details/{ProductId:int?}"@inject ILogger<ProductDetails> Logger@inject IProductRepository Product<PageTitle>Product Details</PageTitle><h1>Product Details Example</h1>@if (details != null){    <h2>@details.ProductName</h2>    <p>        @details.Description        <a href="@details.Url">Company Link</a>    </p>    }else if (loadFailed){    <h1>Sorry, we could not load this product due to an error.</h1>}else{    <h1>Loading...</h1>}@code {    private ProductDetail? details;    private bool loadFailed;    [Parameter]    public int ProductId { get; set; }    protected override async Task OnParametersSetAsync()    {        try        {            loadFailed = false;            // Reset details to null to display the loading indicator            details = null;            details = await Product.GetProductByIdAsync(ProductId);        }        catch (Exception ex)        {            loadFailed = true;            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);        }    }    public class ProductDetail    {        public string? ProductName { get; set; }        public string? Description { get; set; }        public string? Url { get; set; }    }    /*    * Register the service in Program.cs:    * using static BlazorSample.Components.Pages.ProductDetails;    * builder.Services.AddScoped<IProductRepository, ProductRepository>();    */    public interface IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id);    }    public class ProductRepository : IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id)        {            return Task.FromResult(                new ProductDetail()                {                    ProductName = "Flowbee ",                    Description = "The Revolutionary Haircutting System You've Come to Love!",                    Url = "https://flowbee.com/"                });        }    }}

@page "/product-details/{ProductId:int}"@using Microsoft.Extensions.Logging@inject ILogger<ProductDetails> Logger@inject IProductRepository ProductRepository@if (details != null){    <h1>@details.ProductName</h1>    <p>@details.Description</p>}else if (loadFailed){    <h1>Sorry, we could not load this product due to an error.</h1>}else{    <h1>Loading...</h1>}@code {    private ProductDetail? details;    private bool loadFailed;    [Parameter]    public int ProductId { get; set; }    protected override async Task OnParametersSetAsync()    {        try        {            loadFailed = false;            // Reset details to null to display the loading indicator            details = null;            details = await ProductRepository.GetProductByIdAsync(ProductId);        }        catch (Exception ex)        {            loadFailed = true;            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);        }    }    public class ProductDetail    {        public string? ProductName { get; set; }        public string? Description { get; set; }    }    public interface IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id);    }}

@page "/product-details/{ProductId:int}"@using Microsoft.Extensions.Logging@inject ILogger<ProductDetails> Logger@inject IProductRepository ProductRepository@if (details != null){    <h1>@details.ProductName</h1>    <p>@details.Description</p>}else if (loadFailed){    <h1>Sorry, we could not load this product due to an error.</h1>}else{    <h1>Loading...</h1>}@code {    private ProductDetail? details;    private bool loadFailed;    [Parameter]    public int ProductId { get; set; }    protected override async Task OnParametersSetAsync()    {        try        {            loadFailed = false;            // Reset details to null to display the loading indicator            details = null;            details = await ProductRepository.GetProductByIdAsync(ProductId);        }        catch (Exception ex)        {            loadFailed = true;            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);        }    }    public class ProductDetail    {        public string? ProductName { get; set; }        public string? Description { get; set; }    }    public interface IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id);    }}

@page "/product-details/{ProductId:int}"@using Microsoft.Extensions.Logging@inject ILogger<ProductDetails> Logger@inject IProductRepository ProductRepository@if (details != null){    <h1>@details.ProductName</h1>    <p>@details.Description</p>}else if (loadFailed){    <h1>Sorry, we could not load this product due to an error.</h1>}else{    <h1>Loading...</h1>}@code {    private ProductDetail details;    private bool loadFailed;    [Parameter]    public int ProductId { get; set; }    protected override async Task OnParametersSetAsync()    {        try        {            loadFailed = false;            // Reset details to null to display the loading indicator            details = null;            details = await ProductRepository.GetProductByIdAsync(ProductId);        }        catch (Exception ex)        {            loadFailed = true;            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);        }    }    public class ProductDetail    {        public string ProductName { get; set; }        public string Description { get; set; }    }    public interface IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id);    }}

@page "/product-details/{ProductId:int}"@using Microsoft.Extensions.Logging@inject ILogger<ProductDetails> Logger@inject IProductRepository ProductRepository@if (details != null){    <h1>@details.ProductName</h1>    <p>@details.Description</p>}else if (loadFailed){    <h1>Sorry, we could not load this product due to an error.</h1>}else{    <h1>Loading...</h1>}@code {    private ProductDetail details;    private bool loadFailed;    [Parameter]    public int ProductId { get; set; }    protected override async Task OnParametersSetAsync()    {        try        {            loadFailed = false;            // Reset details to null to display the loading indicator            details = null;            details = await ProductRepository.GetProductByIdAsync(ProductId);        }        catch (Exception ex)        {            loadFailed = true;            Logger.LogWarning(ex, "Failed to load product {ProductId}", ProductId);        }    }    public class ProductDetail    {        public string ProductName { get; set; }        public string Description { get; set; }    }    public interface IProductRepository    {        public Task<ProductDetail> GetProductByIdAsync(int id);    }}

Prerendering

Razor components are prerendered by default so that their rendered HTML markup is returned as part of the user's initial HTTP request.

In a Blazor app operating over a circuit, prerendering works by:

• Creating a new circuit for all of the prerendered components that are part of the same page.
• Generating the initial HTML.
• Treating the circuit asdisconnected until the user's browser establishes a SignalR connection back to the same server. When the connection is established, interactivity on the circuit is resumed and the components' HTML markup is updated.

For prerendered client-side components, prerendering works by:

• Generating initial HTML on the server for all of the prerendered components that are part of the same page.
• Making the component interactive on the client after the browser has loaded the app's compiled code and the .NET runtime (if not already loaded) in the background.

If a component throws an unhandled exception during prerendering, for example, during a lifecycle method or in rendering logic:

• In a Blazor app operating over a circuit, the exception is fatal to the circuit. For prerendered client-side components, the exception prevents rendering the component.
• The exception is thrown up the call stack from theComponentTagHelper.

Under normal circumstances when prerendering fails, continuing to build and render the component doesn't make sense because a working component can't be rendered.

To tolerate errors that may occur during prerendering, error handling logic must be placed inside a component that may throw exceptions. Usetry-catch statements with error handling and logging. Instead of wrapping theComponentTagHelper in atry-catch statement, place error handling logic in the component rendered by theComponentTagHelper.

Warning

Use of manual render tree builder logic is considered an advanced and unsafe scenario, not recommended for general component development.

• Handle caught exceptions outside of a Razor component's lifecycle
• ASP.NET Core Blazor logging
• Handle errors in ASP.NET Core†
• Create web APIs with ASP.NET Core
• Blazor samples GitHub repository (dotnet/blazor-samples) (how to download)

• ASP.NET Core Blazor logging
• Handle errors in ASP.NET Core†
• Create web APIs with ASP.NET Core
• Blazor samples GitHub repository (dotnet/blazor-samples) (how to download)