Error Handling Best Practices

Not only log errors, but also log what you’re doing - useful information that might come in handy when troubleshooting in the Logs.

If you’re following our other best practices, each function can be treated as a break point because each function should be doing only one thing.

Some examples of what you might want to log include:

• API requests

• Database requests

• Moving files

• Pre or Post processed messages

You probably don’t need to log details such as every single field that you’re mapping, although including a before and/or after of a message is definitely useful.

Including relevant processing information in the logs is useful for:

• Supportability - you can see what your interface is doing and where issues occur.

• Readability - helps for making your code easier to read, because you can clearly see what the workflows are.

Errors are inevitable, but we can build resiliency in our scripts to handle them gracefully!

To do this you need to anticipate errors, and then catch them using the pcall function and use the error function to trigger pcall with a descriptive message to help with troubleshooting.

This allows you to call functions in a way that if it runs into any kind of coding error, the pcall will simply return false with an error message, rather than cause your script to stop on error.

Open