Add Error Handling Try Catch to Arcade Language

[SylvainHotte2]

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

}

[jcarlson]

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

[RichardJShepherd]

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?

[SylvainHotte2]

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

[JohnFannon]

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.

[DougC]

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

[sofoo]

@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.  

[DWarburg_Locana]

@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

[DeanMoiler]

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.

[DrewDowling]

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.

[JodiLuostarinen]

YES, please.  Got my vote.