Power Platform Community Forum Thread Details

Summary: Starting in version 3.21122 of Power Apps Studio, if a function returns an error, and that error is not captured or handled, the user will see a notification banner with the error details. Before the app behavior may be affected (for example, an error in a label's Text property would cause it to be blank), but now the app is more explicit about telling the user that something wrong happened. This only applies for apps with the 'Formula-level error management' feature enabled. If you want to disable the message shown to the user, you can use the new App.OnError property (see this for more details).

More details: We had quite a few support tickets created where an app was not behaving as expected, and the app creator didn't know what was going on. In many of those cases, the culprit was an error that was returned by some function and caused the app to misbehave. With this change, we expect the users (and makers) to be more aware of errors that happen in the app.

Let's start with an example. I have a table in SQL Server with a 'Value' column that has a constraint that does not allow negative values. And in my gallery, I try to update one of the records with an invalid value:

Before this change, during authoring we would see a red 'X' badge shown near the control, and a new runtime error in the App Checker. However, during preview, or if the app was being played back by a user, nothing would indicate the error. Starting with the version 3.21122, the user will also see the error message in a banner on top of the app, similar to calls to the Notify function.

This doesn't happen only for behavior functions. If the input property of a control is an expression that receives an error value, then an error will also be presented to the user, as shown below.

Notice that if the same error happens multiple times we will not show the same message. However, if the Monitor tool is connected to the app, we will see one entry for each of the errors, as shown below.

You can also see on the screen capture above that in the monitor we also show more details about the error, including where it was created (Source), in which control it surfaced (Observed), and in the case of errors from the network we will also show the full response that caused the error. Notice that this is the same information that the maker can get in the IfError function or in the App.OnError handler.

With this change we are making clear to the user (and maker) what errors are happening in their apps. And with the App.OnError handler we give the makers the power to control how that information is shown. For example, if in an app we only want to show numeric or division by zero errors, and hide all others, we can have an expression like this on the App.OnError:

Error(Filter(AllErrors, Kind = ErrorKind.Div0 Or Kind = ErrorKind.Numeric))

Or if we want to trace the errors to monitor (or an Application Insights instance) all errors, and customize the message that is shown to the user, we can have an expression like this:

Trace("Unhandled error in the app", TraceSeverity.Warning, { errors: AllErrors });
Notify("Unhandled error in the app, please contact the app owner!", NotificationType.Warning)

There are still a few kinks to fix in this feature (for example, some errors in galleries are still not presented to the user, although they are being traced to the monitor), but it should be mostly done.

Hopefully this helps understanding this new behavior on apps, and provide a way to customize how errors are displayed to the user. We will have more detailed information in the official documentation when this release is deployed worldwide. As usual, we want your feedback! Let us know if you have any questions, concerns, suggestions or bug reports on the error handling feature!

Categories:

Error handling