idea Add Error Handling Try Catch to Arcade Language in ArcGIS Pro Ideas

Add Error Handling Try Catch to Arcade Language

SylvainHotte2 — Thu, 03 Mar 2022 21:58:43 GMT

Like any language Arcade should have error handling functionality.

It would be help full to have a Try Catch and be able to get the error description

try {

...code

}

catch (err){

...code

}

Re: Add Error Handling Try Catch to Arcade Language

jcarlson — Wed, 14 Apr 2021 19:16:34 GMT

This is a great idea, I would use this all the time.

Re: Add Error Handling Try Catch to Arcade Language

RichardJShepherd — Wed, 14 Apr 2021 20:32:07 GMT

Thanks for raising the idea, @SylvainHotte2 @jcarlson . We've discussed various plans for adding more error management within Arcade.

We'd be interested in what scenarios you have in mind? For instance:

- catching when something has gone wrong within a library function?

- your own script logic throwing exceptions to be caught in an outer scope of the script?

- being able send your own error/exception information out of the script for the application to receive/log/act on?

Re: Add Error Handling Try Catch to Arcade Language

SylvainHotte2 — Thu, 15 Apr 2021 15:55:19 GMT

Currently I use Arcade in attribute rules. I use the a lot the {"errorMessage":"a message to the user"} to send back error to the user telling them what is the cause of the error.

However, a try catch would be helpful to capture runtime error and send a more descriptive message. Here an Example. In that code sample we validate (Constraint Rule) the the new value the user entered really exist in an other table (we validate the relationship). I edit the code to simplify the example.

In this example, If the Filter returns nothing then First return Null. To prevent a runtime error I need to check for null before getting the .STATUS_CODE attribute. Depending on code there could be many of those kind of check. Also, it might be something wrong with a library, or something we did not think of. I would rewrite like this

In other scenario I written function in my arcade script (ex: recursive, reuse code, etc) I might also be interesting to be able to throw Exception instead of outputting and array like having the first element a Boolean for success or Fail, and the second for the data.

As for sending My own Exception outside I recently see that now the full attribute rule error message we see in pro is not sent to the .Net SDK. That is good. If you could go a step further and being able to the the detail in an object (Rule Name, Error Code, Error Description, etc ) but I guess I can deserialize the Json my self. I also notice the tools like FME does not report error correctly when the is an attribute rule constraint. The is just an generic error message the the message part is just {}.

While I have your attention, I know we are not Christmas yet, but I will be fun to be able to build our own Arcade Function Library and Import them in the Arcade Script. Let say I create a advance TitleCase function, or other generic function that I use in many other script, Instead of copy paste the function, I could just create a library and import it. I could event share those libraries to others.

Hope it give a more detail idea of what I had in mind

Regards

Sylvain

Re: Add Error Handling Try Catch to Arcade Language

JohnFannon — Fri, 05 May 2023 09:10:45 GMT

Absolutely agree that having error trapping (e.g. try/catch) is an essential requirement. This is both for capturing unexpected errors from library functions and for capturing errors within our own code. Without this capability, if we use arcade to do anything slightly more complex, end users can end up with a poor user experience when things go wrong.

Re: Add Error Handling Try Catch to Arcade Language

DougC — Fri, 05 May 2023 09:23:00 GMT

This gets my vote too! Real nightmare handling errors in arcade...

Re: Add Error Handling Try Catch to Arcade Language

sofoo — Fri, 05 May 2023 16:22:03 GMT

@RichardJShepherd Would be great in SmartForms. If a field calculation in Arcade errors out it locks up the SmartForm and refuses to allow the user to submit the feature because having a calculation on a field there makes that field a required field. Unlike in Survey123, there is no "Save Draft" option.

Re: Add Error Handling Try Catch to Arcade Language

DWarburg_Locana — Wed, 10 Apr 2024 23:19:45 GMT

@RichardJShepherd

Another case where this would very useful is catching errors to portal functions such as GetUser() because these methods raise an error when Attribute Rules are triggered by a Server User with a REST token.

For example, the following line in one of our Attribute Rules causes an error when edits are made by an automated integration with SAP using a token at the /applyEdits REST Endpoint.

var devPortalUser = GetUser()

We should have an ability to do this:

try:

var devPortalUser = GetUser()

except:

\\Do Something

Re: Add Error Handling Try Catch to Arcade Language

DeanMoiler — Wed, 20 Nov 2024 14:24:25 GMT

Absolutely agree a try-catch should be included.

Having a similar problem to @DWarburg_Locana with GetUser() returning an error for users no longer in the portal when returning track edits in an archive service.

This is just for a popup rather than to apply edits, so is not critical, but would allow the ability to indicate the user no longer exists rather than simply failing to return a value.

Re: Add Error Handling Try Catch to Arcade Language

DrewDowling — Wed, 20 Nov 2024 17:10:21 GMT

This would be useful, especially for crappy programmers like myself. I frequently forget to test for NULL values in variables, and as a result, my attribute rules crash, and users can't make particular edits.

A catch block would allow me to gracefully fail the edit, possibly send more useful information to the editor, and log the failure.

Re: Add Error Handling Try Catch to Arcade Language

JodiLuostarinen — Wed, 20 Nov 2024 19:26:42 GMT

YES, please. Got my vote.

Re: Add Error Handling Try Catch to Arcade Language

LanceKirby2 — Thu, 21 Nov 2024 03:07:09 GMT

One more vote!

Re: Add Error Handling Try Catch to Arcade Language

PeterKnoop — Thu, 02 Jan 2025 14:41:51 GMT

A try/catch capability would potentially help with the goal of capturing whether the current user has access to a data source, and if not, then return a message in a List widget, rather than popping up the login dialog.

For example, one could wrap FeatureSetByPortalItem with a try/catch to handle the error returned when a user does not have access to a portal item.

Re: Add Error Handling Try Catch to Arcade Language

DavidStewart3 — Thu, 09 Jan 2025 19:14:00 GMT

YES, Please do this.

Here is an Arcade expression code snippet where an error trap would be useful. (This is part of an Arcade expression used to populate an enterprise portal WebMap popup.) As it is, the expression executes fine when one or more features satisfy the filter condition, but fails (ie returns nothing) when no features are found:

var returnText = "ipsum dolorum";

var allFeatures = FeatureSetByPortalItem(port, mapID, layerID);

var where = 'CNTRCT_ID=<some value>';

var foundFeatures = Filter(allFeatures, where); // code fails at this point

if (foundFeatures == null)

returnText = "No features found";

else

returnText = Count(foundFeatures) + " features were found";

return returnText;

Re: Add Error Handling Try Catch to Arcade Language

jrosacker — Tue, 13 May 2025 20:12:11 GMT

Interestingly, Esri has reserved some relevant keywords in Arcade:

Hopefully this idea gets approved!

Re: Add Error Handling Try Catch to Arcade Language

HuajunChenGarland — Tue, 26 Aug 2025 15:02:08 GMT

Yes, please.

It is how I want to use it.

function ToDateSafe(val) {

var d = null;

try {

d = Date(val);

}

catch(err) {

d = null;

}

return d;

}

Re: Add Error Handling Try Catch to Arcade Language

JBH — Mon, 02 Feb 2026 13:24:46 GMT

Yes, need!

Re: Add Error Handling Try Catch to Arcade Language

RobinKurosawa — Mon, 02 Feb 2026 15:47:46 GMT

+1 to this thread.

Without a way to explicitly handle failures, engineers are forced to rely on defensive patterns and implicit failure behavior. This makes logic harder to test, harder to audit, and harder to build on top of, and harder to fix — especially when expressions cannot be easily executed or tested outside the platform.