You’re offline. This is a read only version of the page.
Summary: we have a new property on release version 3.21112 of the Power Apps Studio in the App object: OnError, which can be used to handle any errors that are not done in the controls themselves, so that they are not bubbled up to the app and displayed to the user. This will be important in the coming releases as we start showing unhandled errors to users (which currently is not done).
More details:
In the release of version 3.21112 of Power Apps Studio, we added a new behavior property to the App object: OnError. This property can be used to handle any runtime errors that were not handled in the app. In this property we get the same scope variables ‘FirstError’ and ‘AllErrors’ as we do in the IfError function, so the app can get information about the origin and where the errors surfaced, in addition to the error kind, message and possible additional details.
Furthermore, since that is a behavior property, the app can take actions that they normally couldn’t inside “data” properties, such as sending the error information to a data source or using the Trace function to send it to an Application Insights instance or a Monitor that is connected to the app (although we will be changing the default implementation to do that soon). The App.OnError can also choose which of the errors that it received that will “bubble up” to the application (which would be the case if there were no expressions inside App.OnError).
Let's have some examples. This is a very simple app with two labels that do calculations based on a text input control. As we change the value of the text input, some of the calculations start returning errors, and they are shown in the Studio (both as red 'X' badges and in the App Checker). We call those "unhandled" errors because they were tried to be used as properties of controls, which cannot handle them.
We could have handled the error directly in the labels. For example, the current expression for the top label is the following:
Share
Report"1 / <Value> = " & 1 / Value(TextInput1.Text)
And we could use the IfError function to replace the error with another value, like in the example below:
"1 / <Value> = " & IfError(Text(1 / Value(TextInput1.Text)), "<error>")
Which would "handle" the error in the function itself:
App.OnError gives makers a "last stop" before the errors are considered unhandled. And since it is a behavior property, it can use functions such as Trace, Patch, and others that are not available in a Text property of a label, for example. Let's do that, by setting App.OnError to the following expression:
Trace("Error at " & FirstError.Observed & ": " & FirstError.Message)
And as we interact with the app, we can see that the errors are not displayed anymore in the authoring environment - the App.OnError expression "handled" the errors, by sending them to the Trace function (which we can see the result in the monitor).
Notice that currently there are also some error events that are being traced to the monitor - we are tracing most of the errors, even if they are properly handled. We received feedback that this is noisy, and we will be removing those, and tracing only those that are unhandled by the app.
But maybe we want to not only trace the errors that were not handled by the app, but also "bubble them up" or "rethrow" those errors so that they will get the treatment of other unhandled errors (which, starting in a few weeks, will be to be displayed to the user, both during authoring and when the app is being played back). We can also do that in App.OnError, by using the (currently undocumented, will update this post when the documentation is ready) Error function, which can take either one or multiple errors as a parameter. So if we replace the existing App.OnError expression with this:
Trace("Error at " & FirstError.Observed & ": " & FirstError.Message); Error(AllErrors)
We will both see the errors being traced, and the red 'X' badge that indicates that the error was not handled.
Notice that you can "rethrow" only a subset of errors. For example, if you don't want the division by zero errors to be shown to the user, we can update the expression to the following:
Trace("Error at " & FirstError.Observed & ": " & FirstError.Message);
Error(Filter(AllErrors, Kind <> ErrorKind.Div0))
And in this case the negative square root error will be considered unhandled in the example above.
One thing worth mentioning is that App.OnError will run after the error has been returned by an expression. Its goal is to report errors, log them, suppress them, or in general take control of what the user will see when those errors happen. However, unlike a function such as IfError, App.OnError cannot be used to replace an error with another value in the expression.
As I mentioned before, in a few weeks we will start showing all unhandled errors to the user. If you don't want the app to have that, you can proactively implement any logic in App.OnError to either completely ignore them (any expression would do, such as "false"), or log / trace them to some place where you can better understand where your users are hitting errors in their apps.
As usual, we want your feedback! Let us know if you have any questions, concerns, suggestions or bug reports on the error handling feature!
Hi @GringoInMiami the App.OnError refers to the OnError property of the App object. It's a behavior property, so it can only be defined, not accessed. The screen capture below shows an example of it. Notice that we just announced that the Error Handling feature is not an experimental feature anymore (it's now Preview), and the version where this change was made (3.22082) still hasn't reached all regions. Before that is done we will have the official documentation that talks about that property and other aspects of error handling.
Example of the App.OnError property
Hope this helps!
What are the acceptable values for the OnError App property?
@mdevaney your expression doesn't return any errors - so as far as the app is concerned, there are no unhandled errors. When there are errors in the 'Attendance List', the call to Notify will be made, and it will "succeed" - by showing a banner to the user.
However, if there was a call before that - for example, a Patch to the 'Attendance List' data source - and that call returned an error, then yes, the result of the expression below would be considered an unhandled error:
All responses (
Answers (
Patch(
'Attendance List',
Default('Attendance List'),
{ Name: "John Doe", Value: -1 }); // If (-1) is not a valid value for 'Value',
// there will be an error in this expression
If(
IsEmpty(Errors('Attendance List')),
Navigate('Home Screen'),
Notify("There was an error", NotificationType.Error)
)
Hope this helps!
@CarlosFigueira
Error-handling is currently done like this in my Power Apps. Will App.OnError consider the error handled or unhandled?
If(
IsEmpty(Errors('Attendance List')),
Navigate('Home Screen'),
Notify("There was an error", NotificationType.Error)
)
---
Please click "Accept as Solution" if my post answered your question so that others may find it more quickly. If you found this post helpful consider giving it a "Thumbs Up."
I will definitely be using this going forward as I've recently found the lack of detail within the monitor sessions to be a blocker (i.e when it just shows multiple 'null' responses that do not indicate where they originated from).
Thanks for adding this! 😻
Stay up to date on forum activity by subscribing.
#1
stampcoin
58
#2
DS-11051211-0
20
#3
MS.Ragavendar
9