dotnet/AspNetCore.Docs · error · InvalidOperationException

Current count is over five!

Error message

Current count is over five!

What it means

Demo throw used to show Blazor's global error processing via a [CascadingParameter] ProcessError component. When currentCount exceeds 5 the component throws InvalidOperationException("Current count is over five!"), but unlike errors 42/43 it is caught locally and forwarded to ProcessError?.LogError(ex) for centralized logging/UI. Illustrates graceful per-component error capture.

Source

Thrown at aspnetcore/blazor/fundamentals/handle-errors.md:618

* Call an error processing method in any `catch` block with an appropriate exception type. The example `ProcessError` component only offers a single `LogError` method, but the error processing component can provide any number of error processing methods to address alternative error processing requirements throughout the app. The following `Counter` component `@code` block example includes the `ProcessError` cascading parameter and traps an exception for logging when the count is greater than five:

  ```razor
  @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:

> :::no-loc text="fail: {COMPONENT NAMESPACE}.ProcessError[0]":::  
> :::no-loc text="ProcessError.LogError: System.InvalidOperationException Message: Current count is over five!":::

If the `LogError` method directly participates in rendering, such as showing a custom error message bar or changing the CSS styles of the rendered elements, call [`StateHasChanged`](xref:blazor/components/lifecycle#state-changes-statehaschanged) at the end of the `LogError` method to rerender the UI.

Because the approaches in this section handle errors with a [`try-catch`](/dotnet/csharp/language-reference/keywords/try-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 on [how a circuit reacts to unhandled exceptions](#unhandled-exceptions-for-circuits).

View on GitHub (pinned to c67a80103a)

Solutions

  1. Ensure a ProcessError component is supplied as a CascadingValue ancestor so ProcessError is non-null (otherwise errors are silently swallowed).
  2. Verify ProcessError.LogError actually persists/logs (check the logged output shown in the doc).
  3. Replace the artificial threshold with real domain logic in production.
  4. Consider rethrowing or surfacing UI feedback after logging if the user must be notified.

Example fix

// before
catch (Exception ex)
{
    ProcessError?.LogError(ex);
}

// after — also notify the user and guard against null cascading value
catch (Exception ex)
{
    if (ProcessError is null)
    {
        logger.LogError(ex, "No ProcessError cascading value available.");
    }
    else
    {
        ProcessError.LogError(ex);
    }
    errorMessage = "Something went wrong. Please try again.";
}
Defensive patterns

Strategy: try-catch

Validate before calling

if (currentCount > 5) { currentCount = 5; return; }

Try / catch

try { /* increment logic */ }
catch (Exception ex)
{
    if (ProcessError is not null) ProcessError.LogError(ex);
    else logger.LogError(ex, "ProcessError cascading value not supplied.");
    errorMessage = "Unable to increment.";
}

Prevention

When it happens

Trigger: Incrementing the counter past 5. The local try/catch swallows the exception and routes it to the cascaded ProcessError service, which logs it.

Common situations: Adopting the documented global error-handling pattern; wiring a ProcessError cascading value across components; testing that LogError fires on the rendered exception.

Related errors


AI-assisted analysis of dotnet/AspNetCore.Docs@c67a80103a (2026-08-13). Data as JSON: /api/errors/1d89a7011786e7de. Report an issue: GitHub.