Showing results for 
Search instead for 
Did you mean: 
Power Apps
Power Apps

New property (App.OnError) on version 3.21112

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:



"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!


Helpful resources

UG GA Amplification 768x460.png

Launching new user group features

Learn how to create your own user groups today!

Community Connections 768x460.jpg

Community & How To Videos

Check out the new Power Platform Community Connections gallery!

M365 768x460.jpg

Microsoft 365 Collaboration Conference | December 7–9, 2021

Join us, in-person, December 7–9 in Las Vegas, for the largest gathering of the Microsoft community in the world.

Users online (2,477)