Introduction to Exceptions Handling

It’s Monday morning, and before you’ve even had your first cup of coffee (or tea if that’s your fancy) you have your first user asking for your attention, and way too many unread messages on your phone and in the inbox (all related to message failures in the middleware). This is nothing new for Monday, in fact, it’s pretty run-of-the-mill. Sounds familiar? 

A lot of developers spend too much time on root cause analyses just to find that it was a data integrity issue – which should be solved by the business. Or they find out if’s a service that was in maintenance mode… again – which means that an admin needs to head to his keyboard. Both of these scenarios are a waste of your precious time, especially when it’s rare that an issue needs a developer to take action. We all know the frustration of wasting all that time analyzing issues, and because of this you can’t start on that project that was due last week.

These issues are often caused by poor Exception handling or Exception reporting or a combination of both. As a developer, we sometimes have to adopt integration solutions where Exception handling and reporting were an afterthought.  Then again, you might be wondering if it’s wise to report each possible exception in a flow.

Exception handling is all about being able to catch almost all exceptions. In the case of a synchronous solution a flow needs to be able to return a response in almost all situations. Asynchronous solutions might not need to give a response but an exception should be detectable.

A slightly destructive mindset can help to find which type of exceptions you might need to handle in all those solutions, which can range from data integrity, services down or a missed update on a service – but that is only some of the possible causes.

Exception reporting is all about returning or creating a descriptive message for the party that needs to solve the exception. From experience this is often someone else in the organization or a third party consuming an API. Exception descriptions often need translating to hide implementations, add context or simplification, among other things.

This blog series is designed to help you with Exception handling/reporting, so you can make more efficient use of your time. In this series of blog posts we are going to work on a POC that can help with the exception handling and reporting. In this POC we want to be able to use a dynamic system based on a database backend. This also aimed at an audience that are relatively new to Azure and involves multiple components and techniques. Just a short list of what we will cover:

1. CosmosDB
2. Azure Functions
3. WebApps
4. LetsEncrypt certificates
5. Logic apps
6. API Manager

Others may be added in the future. Stay tuned for the first blog post in this series which will deal with CosmosDB!