Handling Errors in Blazor with ILogger and Try-Catch Patterns

Blazor applications move significant amounts of application logic into the browser or a server-side circuit. That architecture delivers a responsive experience, but it also changes how failures appear and where they should be handled. A database timeout, invalid form submission, expired authentication token and rendering exception each require a different response.

A reliable approach combines structured logging through ILogger, narrowly scoped try-catch blocks, Blazor error boundaries and clear user-facing messages. For Australian teams building systems for government, finance, education or retail, the design must also account for privacy obligations, regional Azure services and users working with variable network quality across metropolitan and regional areas.

Identify The Failure Before Handling It

Errors in Blazor generally fall into three useful categories: expected business failures, recoverable infrastructure failures and unexpected programming defects. An invalid ABN, a duplicate booking or a missing form field is an expected condition. It should usually become a validation message rather than an exception. A temporary API timeout may be recoverable with a retry or a prompt to try again. A null reference or broken component state requires logging, investigation and a safe fallback.

This classification prevents broad exception handling from hiding defects. A catch (Exception) around an entire page event may keep the interface alive, yet it can also turn a serious bug into an empty result. Catch only exceptions that the current method can meaningfully handle, and allow unexpected errors to reach a central boundary or middleware layer.

Consider the scope of the operation as well. A failure while loading a dashboard should not necessarily terminate an entire Blazor Server circuit. Conversely, a corrupted authentication state or a failed initial render may require the application to reset the view or send the user back to a safe route.

Configure ILogger For Useful Diagnostics

Inject ILogger<TCategory> into components, services and hosted background processes rather than writing directly to the console. The category created from the type name helps operators locate the source of a problem and filter logs by feature.

@inject ILogger<OrderSummary> Logger

@code {
    private async Task LoadOrderAsync()
    {
        try
        {
            order = await OrderService.GetAsync(OrderId);
        }
        catch (HttpRequestException ex)
        {
            Logger.LogWarning(ex,
                "Order request failed for {OrderId}", OrderId);

            errorMessage = "The order could not be loaded right now.";
        }
    }
}

Use structured message templates such as {OrderId} instead of string interpolation. Log levels should communicate operational meaning: Debug for development detail, Information for significant workflow events, Warning for recoverable problems and Error for failures that need investigation. An exception object should be passed as the first argument after the message template so that its stack trace and inner exceptions are retained.

Avoid logging passwords, access tokens, payment details, health information or complete request payloads. In an Australian deployment, the Privacy Act 1988 and the Notifiable Data Breaches scheme make careless diagnostic data a genuine operational risk. Log identifiers that support tracing, but keep sensitive values masked or excluded.

Apply Try-Catch Around Recoverable Work

A try-catch block belongs close to the operation that can recover from a known failure. Service methods are often the best location because they can translate transport exceptions into a consistent result without forcing every component to understand HTTP, database or queue details.

public async Task<Result<Customer>> SaveAsync(Customer customer)
{
    try
    {
        var response = await client.PostAsJsonAsync("api/customers", customer);

        if (!response.IsSuccessStatusCode)
        {
            return Result<Customer>.Failure(
                "The customer record could not be saved.");
        }

        var saved = await response.Content
            .ReadFromJsonAsync<Customer>();

        return Result<Customer>.Success(saved!);
    }
    catch (HttpRequestException ex)
    {
        logger.LogError(ex, "Customer save request failed");
        return Result<Customer>.Failure(
            "The service is temporarily unavailable.");
    }
}

The component can then display the result without exposing implementation details. This pattern is preferable to catching an exception, logging it and returning null, because a null value may create a second, misleading rendering failure. Result objects, discriminated outcomes or typed service responses make success and failure explicit.

Do not use exceptions for normal validation or expected branching. Validate fields before calling the service, return meaningful domain errors from business operations and reserve exceptions for conditions that interrupt the normal flow. If a catch block cannot recover, add context and rethrow with throw;, never throw ex;, which resets the original stack trace.

Keep Component Rendering Safe

Blazor components can fail during event callbacks, parameter setting and rendering. A local event handler can show an operation-specific message, while an ErrorBoundary provides a broader safety net for child components.

<ErrorBoundary @ref="boundary">
    <ChildContent>
        <InvoicePanel InvoiceId="@InvoiceId" />
    </ChildContent>
    <ErrorContent Context="exception">
        <p class="alert alert-danger">
            This panel is temporarily unavailable.
        </p>
    </ErrorContent>
</ErrorBoundary>

@code {
    private ErrorBoundary? boundary;

    private void ResetPanel()
    {
        boundary?.Recover();
    }
}

An error boundary should be paired with logging. Its fallback content protects the interface, but the exception still needs to be recorded by an appropriate logger or global error pipeline. In production, avoid displaying exception.Message directly because it may reveal database names, internal URLs or implementation details.

For event callbacks, set loading and error state deliberately and use finally to restore the busy indicator. This avoids a button remaining disabled after a failed request.

private async Task SubmitAsync()
{
    isSaving = true;
    errorMessage = null;

    try
    {
        var result = await CustomerService.SaveAsync(model);

        if (!result.Succeeded)
            errorMessage = result.Error;
    }
    catch (Exception ex)
    {
        Logger.LogError(ex, "Unexpected failure while saving customer");
        errorMessage = "An unexpected error occurred.";
    }
    finally
    {
        isSaving = false;
    }
}

Account For Blazor Hosting Differences

Blazor Server executes component code on the server and maintains a SignalR circuit between the browser and the application. A dropped connection, reverse proxy timeout or server-side exception can affect the circuit. Log circuit-related failures with a correlation identifier and provide a reconnection experience that explains what the user can do next.

Blazor WebAssembly runs much of the application in the browser. It cannot access server-side logging providers directly, and exceptions may be affected by browser storage, CORS policies, failed downloads or restricted network conditions. Send selected client-side errors to a protected API endpoint, or use browser telemetry that is configured to remove private data. Treat all browser code as observable by the user; never place secrets in WebAssembly configuration.

Hybrid applications and newer render modes can combine server and client execution within the same solution. Confirm where each service runs before choosing a logging destination. A log statement in a shared library may appear in the server logs for one render mode and require client forwarding in another.

Australian teams frequently deploy to Azure Australia East or Australia Southeast to support latency, data residency and service availability requirements. Even with a nearby region, a user in regional Queensland or Western Australia may experience very different connectivity from someone in Sydney or Melbourne. Design retries, timeouts and offline-friendly messages around real network conditions rather than assuming a consistently fast connection.

Centralise Correlation And Observability

A useful log entry should answer what happened, where it happened and which operation was affected. Use a correlation ID across the browser request, API, service layer and background processing. Activity and OpenTelemetry can propagate trace context across HTTP calls, while Application Insights or another supported platform can collect logs, traces and dependency failures.

using var scope = Logger.BeginScope(new Dictionary<string, object>
{
    ["CorrelationId"] = correlationId,
    ["CustomerId"] = customerId
});

Logger.LogInformation("Starting customer profile update");

Scopes add consistent context without repeating every property in every message. Establish retention and access rules for logs, especially when support staff or external vendors can view monitoring data. Timestamps should be stored consistently, with the user interface converting them to a suitable Australian time zone when needed. This avoids confusion during daylight-saving changes between Sydney, Melbourne, Brisbane and Perth.

Monitoring should measure more than exception counts. Track failed requests, retry volume, circuit reconnections, slow dependencies and error rates by application version. A sudden increase after a deployment may indicate a regression, while a short spike during an external provider outage may require a temporary operational response.

Match Responses To User And Business Needs

The message presented to a user should be specific enough to support the next action without exposing internals. “Your payment could not be processed; check the card details or try again” is more useful than “System error”. A read-only page may offer refresh and retry, while a transaction page should clearly state whether the operation may have completed before the connection failed.

Retries must be selective. Automatic retries are appropriate for transient network errors and some 5xx responses, but they can duplicate a non-idempotent order or payment submission. Use idempotency keys for operations that may be repeated, apply exponential backoff with jitter and stop after a small number of attempts. Do not retry validation failures, authentication failures or permission errors.

The local market can influence these decisions. An Australian retail application may need to cope with mobile users moving between Wi-Fi and cellular networks, while a public-sector portal may need accessible error messages and predictable audit records. When a service handles personal information, align telemetry, support procedures and retention with the organisation’s privacy policy and applicable Australian requirements.

Build A Consistent Error Handling Routine

A shared approach keeps individual components from inventing incompatible logging and recovery behaviours. Define service-level result types, standardise correlation fields, configure production log filtering and test both expected failures and unexpected exceptions. Include component tests for fallback content, integration tests for failed API calls and end-to-end tests for reconnection or expired sessions.

Useful implementation practices include:

• Catch exceptions only where the code can recover or add meaningful context.
• Use structured ILogger templates with stable property names.
• Protect logs from passwords, tokens, payment data and unnecessary personal information.
• Add ErrorBoundary around significant UI regions and provide a clear recovery action.
• Use bounded, idempotent retries for genuinely transient operations.
• Monitor failures across client, API, dependency and circuit layers.

Review the behaviour under slow connections, unavailable APIs and partial deployments. A resilient Blazor application does not pretend errors never occur; it makes failures observable to engineers, understandable to users and safe for the business to manage.