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
- Ensure a ProcessError component is supplied as a CascadingValue ancestor so ProcessError is non-null (otherwise errors are silently swallowed).
- Verify ProcessError.LogError actually persists/logs (check the logged output shown in the doc).
- Replace the artificial threshold with real domain logic in production.
- 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
- Always supply a ProcessError CascadingValue ancestor so the cascading parameter is non-null.
- Verify ProcessError.LogError actually persists.
- Surface user feedback after logging.
- Replace artificial thresholds with real validation.
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
- Current count is too big!
- Skip 3
- QR code size must be less than {MaxQrSize}.
- worker exports not loaded
- Unknown command: ${e.data.command}
AI-assisted analysis of dotnet/AspNetCore.Docs@c67a80103a (2026-08-13).
Data as JSON: /api/errors/1d89a7011786e7de.
Report an issue: GitHub.