How to use IfError in Power Apps

IfError is a function in Power Apps to handle expected and unexpected errors in your code. There are however, a few issues you may run into if you don’t exactly know how this function works.

IfError the basics

In its simplest form IfError will let you run some code, when it fails an alternative code will run. This alternative code is calls fallback code.

In the example below the CountRows function will return the number of rows in a table, however when we are offline, this will fail and a notification is sent to the user.

IfError(
    CountRows(Accounts)
,
   Notify("CountRows on Accounts Failed", NotificationType.Error)
);

In a similar way we could also get IfError to return alternative values as shown in the example below. The value 0 will be returned if x is 0 and a division by 0 would occur.

IfError( 1/x, 0 )

Common IfError mistakes made

Now we have a few mistakes that are made quite often.

First of all I would only use the IfError function with two parameters as shown in the earlier example.

The following example is invalid. Even though Power Apps will not tell you that this is wrong as there is a syntax possible for this. I will get to this later.

IfError(
    CountRows(Accounts)
,
   Notify("CountRows on Accounts Failed", NotificationType.Error)
' 
   Notify("CountRows on Accounts Succeeded", NotificationType.Success)
);

In the above example you might thing that the IfError works like a If Then Else, but that is not the case.

Another commonly made mistake is to run multiple lines of code. Again this is possible. But the code included in the first parameter of the IfError function is always run completely, even if there are failure.

IfError(
    CountRows(Accounts);
    Notify("CountRows on Accounts Succeeded", NotificationType.Success)
,
   Notify("CountRows on Accounts Failed", NotificationType.Error)
);

If we run the above code in the Power Apps app, while we are offline. We will get the followng notifications. So the IfError will still identify that something has gone wrong, but it it will continue to run all code before the fallback code is run as well.

Using failure data

Now consider the following example.

IfError(
    Set(varMyCount, CountRows(Accounts));
    Notify("CountRows on Accounts Succeeded", NotificationType.Success)
    Notify("Count is:" & varMyCount ")" , NotificationType.Success)
    Notify("The end", NotificationType.Success)
,
   Notify("CountRows on Accounts Failed", NotificationType.Error)
);

When we are offline we will see the following result. As explained earlier the 4 lines in the first parameter of the IfError will run, however the second notify is not doing anything as the CountRows failed making our varMyCount variable have an error status.

Now for a simple notification missing you might not even notice the issue, however if one patch depends on data from another patch then your databases may not be update as expected. In other programming and scripting languages this behaviour is often referred to as Silently Continue.

Then and approach as shown below could be useful as well.

IfError(
    Set(varMyCount, CountRows(Accounts));
    Set(varWeAreOnline, true)
,
    Set(varWeAreOnline, false)
);

If(varWeAreOnline,
    Notify("CountRows on Accounts Succeeded", NotificationType.Success)
    Notify("Count is:" & varMyCount ")" , NotificationType.Success)
    Notify("The end", NotificationType.Success)
,
    Notify("CountRows on Accounts Failed", NotificationType.Error)
);

In the above example, I know that there is a Connection.Connected available, however as mentioned in last week’s post there can be some issues with that.

More than two parameters in IfError

Now we could take all of this a step further. In the example below if the first CountRows works the second CountRows will run as well. If however the first one fails we’re going to find that the second CountRows will not run.

Set(varErrorOccured, 
    IfError(
           Notify("Contacts:" &  CountRows( Contacts)) 
        , 
           Notify( "problem in the first action" ); 
           true
        ,
           Notify("Accounts:" & CountRows( Accounts ))
        , 
           Notify( "problem in the second action" ); 
           true
        ,
           false
    )
)

To get the actual error message ( expect quite a few “an unknown error occurred” and other ugly message that Power Apps gives you like “Error when trying to retrieve data from the network”) you can use FirstError and AllErrors. Both of these give you 5 properties:

• Kind
• Message
• Source
• Observed
• Details

The above can help you a lot!

Set(varErrorOccured, 
    IfError(
           Notify("Contacts:" &  CountRows( Contacts)) 
        , 
           Notify( "problem in the first action" ); 
           Notify(FirstError.Message);
           true; 
        ,

            Notify("Accounts:" & CountRows( Accounts ))
        , 
            Notify( "problem in the second action" ); 
            true,
        false
    )
);

Compatible Types

As we saw earlier the IfError will give us multiple places where we supply our return values. We will need to make sure that every return value uses the same type. The below example obviously doesn’t follow this rule and will therefore fail.

IfError(1/x, "Oops")

Final thought

Do you ever write code in Power Apps without IfError? Stability and robustness of apps is absolutely critical if you want to develop professional apps. IfError should be the start of a lot of the error handling needed. Even if nothing ever goes wrong.