Try/Catch in SciptInclude/ClientScript

[swisstech08]

Hi,

I was wondering what best practice for try/catch is.

I use a try/catch block in my Script Include wrapped around a REST message call. I parse the REST call return for the REST Message Body and REST Message Status. If the status is not a successful http = 200, I catch the issue and log it to the SN log system. However, I also want inform the Catalog Item user if an issue occured with the REST Message call by providing an alert message: alert("Host Could Not Be Contacted");   or something similar.

The question I have

1) Is it better to trap the status error, send the error value, like 401/500, back to the Client Script and then in the Client Script provide an error message

2) Is it better to trap the status error in the Script Include and pass an error message to the Client Script and display that error message in an alert.

The Script Include passes a JSON string to the Client Script if the action is successful. How would I check in the Client Script which message was returned. If I send an integer value to the Client Script that would be easier to check.

Sincerely,

Roland

[Alikutty A · Accepted solution]

Hello,

It is always better to trap errors to the minute level as possible and you will need to decide on what level of message is required to be displayed to an end user or to an admin user. You don't have to display server side error messages to the users. They should worry about a 404 or 500. Users should always be presented with a friendly message which is understandable to them. For eg: We were not able to process your request - You can try again later, or you can contact system administrator or open a trouble ticket. 

You can add the try-catch in both client and server side scripts. On the server side, you can add logs to the system log table so that an admin could debug the issue which may be reported later. On the client script, you may catch these issue and alert user with something meaningful. You don't need to send back the error to the client side, as the try catch at the client side should have already caught it with a different exception message at the specific line which calls the server side functionality. You can use this error and display something meaningful alert to the user. You could also use some generic messages for the admin to determine on which script triggered it and the admin could later validate the errors from the system logs.

Thanks!

[Deepak Ingale1]

Hello,

Below are some examples and documentation around how client to server communication happens via AJAX calls

https://docs.servicenow.com/bundle/geneva-servicenow-platform/page/script/server_scripting/reference...

https://docs.servicenow.com/bundle/geneva-servicenow-platform/page/script/server_scripting/reference...

1) Is it better to trap the status error, send the error value, like 401/500, back to the Client Script and then in the Client Script provide an error message : You can definitely do that by constructing a JSON object, put the error message in stringed JSON https://blogs.dxc.technology/2016/11/17/glideajax-return-multiple-values-using-json/

2) Is it better to trap the status error in the Script Include and pass an error message to the Client Script and display that error message in an alert. Yes, we can do it

The Script Include passes a JSON string to the Client Script if the action is successful. How would I check in the Client Script which message was returned. If I send an integer value to the Client Script that would be easier to check.

You can directly pass on the error message from Server to Client as well 

Note: Please mark reply as correct / helpful if it has answered your question