When it comes to errors and interfaces there is a little more to think about than first comes to mind.

The bad news is that error handling is specific to your application, the type of interface you are implementing and whatever technologies you are using. If you are doing at interfacing at scale this is a topic you’ll find value in thinking through at some point.

The good news is that Iguana gives you the control to determine exactly how errors will be handled. So don’t worry. Take a break, get a cup of coffee and quietly go through the exercise outlined here. It will pay itself back with a lot less drama in production.

Here are some points to consider.

Not all errors are equal. This is the most important point to realize. If you want things to work smoothly at scale it’s helpful to think through the errors you anticipate and plan on what you want your interface in Iguana to do.

Sometimes retrying makes sense. Let’s say for instance you know it’s common for the database you are feeding into to go offline for backups.  Then desirable behaviour for the interface would be to have it go to sleep and retry periodically until the backup is done. That can easily be achieved using our retry module as a starting point.

Some errors should be fatal. In some cases an error represents a serious logic error in the interface. In this case you do want the interface to stop. The problem then needs to be fixed before the interface can be safely restarted. This is the default behavior unless you use the iguana.stopOnError function.

Sometimes skipping bad transactions is correct.  Let’s say the interface is something non critical – like getting demographics into your application.  Maybe the other side sends you an unexpected message that you didn’t expect. In this case logging a warning and skipping the message makes sense.

Fortunately the Iguana translator environment makes it easy to get the tight control over the error handling that you need to handle all these scenarios. You can use pcall function to catch errors and figure out what type of error message you have and then execute the desired behavior.

What I recommend to you, is to make a two column table. On the right side write down the errors you anticipate and on the left side write down the desired behavior.

Once you have clearly thought it through, then implementing this as part of your standard module should be straightforward. Typically this stuff should be boilerplate – the same for all your interfaces. Over time you are likely to understand your interfaces better and how they have issues and do a better analysis of the desired error handling.

If you have questions or comments about this please feel free to ask – we’re here to help.