Error Handling with IfError

Analogy categoryAnalogies

Why Formulas Need Error Handling

Operations like dividing by zero, calling Patch against a data source with a validation rule the record violates, or converting text that isn't actually numeric with Value() can all fail at runtime, and by default a failed formula produces a visible error banner and leaves the affected control showing an error state. IfError(Formula1, FallbackResult1, [Formula2, FallbackResult2, ...], [FinalFallback]) evaluates Formula1, and if it produces an error, returns FallbackResult1 instead of letting that error surface — this is the direct Power Fx equivalent of a try/catch block in a traditional programming language, except expressed as a single formula rather than a statement block.

🏏

Cricket analogy: IfError is like a third umpire's fallback ruling: if the primary technology (Hawk-Eye) fails to produce a clear reading, the decision falls back to the on-field umpire's original call instead of the broadcast simply showing an error screen.

Using IfError with Data Operations

A very common pattern wraps a Patch call in IfError so that a validation failure — say, a Dataverse business rule rejecting a negative quantity — shows the user a friendly Notify() message instead of a default error toast: IfError(Patch(Orders, Defaults(Orders), {Quantity: varQty}), Notify("Could not save: check quantity", NotificationType.Error)). Because IfError itself is a normal Power Fx function (not restricted to behavior properties the way Patch is), it can also wrap non-behavior formulas, such as safely parsing user-entered text with IfError(Value(txtAmount.Text), 0) so a non-numeric entry falls back to zero instead of making the whole formula error out.

🏏

Cricket analogy: Wrapping Patch in IfError is like a team submitting a player-registration form that the board might reject for an eligibility issue — instead of the whole submission process crashing, the team gets a specific rejection reason and can fix it.

Errors() and the App-Level Error Table

Beyond IfError's per-formula catching, Power Apps also maintains an app-wide, automatically populated Errors() table recording the details of data-source errors (which record, which column, what the error message was), which is useful for building a dedicated diagnostics panel or logging errors centrally rather than handling every possible failure inline with IfError everywhere. The two approaches are complementary: IfError is for formulas where you know a specific failure is plausible and want a specific fallback right there, while Errors() is for broader visibility into what went wrong across the app, particularly during testing and debugging.

🏏

Cricket analogy: IfError catching one risky formula is like a fielder positioned specifically for a likely shot, while Errors() is like the team's overall match-incident log capturing every notable event across the whole innings for later review.

powerfx

// Wrap a risky Patch so validation failures show a friendly message
SaveButton.OnSelect = IfError(
    Patch(Orders, Defaults(Orders), { Quantity: Value(txtQty.Text), CustomerID: varCustomerID }),
    Notify("Could not save order: " & FirstError.Message, NotificationType.Error)
)

// Safely parse user text input, falling back to 0 on bad input
Set(varAmount, IfError(Value(txtAmount.Text), 0))

// Inspect the app-wide error table after an operation
Gallery1.Visible = CountRows(Errors(Orders)) = 0

Inside IfError's fallback expression, the special FirstError record (and FirstError.Message specifically) exposes details about the error that was caught, which is what makes it possible to show a genuinely useful message to the user rather than a generic 'something went wrong'.

IfError only catches errors from the specific formula it wraps — it does not catch errors thrown later by an unrelated formula elsewhere in the app, and wrapping every single formula defensively in IfError 'just in case' makes formulas harder to read without actually preventing more bugs. Reserve IfError for operations that can plausibly fail at runtime (Patch, Value() on user input, division), not as a blanket habit.

IfError(Formula, Fallback, [...], [FinalFallback]) catches a runtime error and substitutes a fallback value.
It is Power Fx's equivalent of try/catch, expressed as a single formula rather than a statement block.
Common uses: wrapping Patch to catch validation failures, and wrapping Value() to handle bad text input.
FirstError.Message inside the fallback exposes details about the specific error that was caught.
Errors() is an app-wide table automatically tracking data-source errors, complementary to IfError.
IfError only catches errors in the specific formula it wraps, not errors elsewhere in the app.
Reserve IfError for operations that can plausibly fail, not as a blanket wrap on every formula.