Azure Functions error handling
Handling errors in Azure Functions is important to avoid lost data, missed events, and to monitor the health of your application.
This article describes general strategies for error handling along with links to binding-specific errors.
Errors raised in an Azure Functions can come from any of the following origins:
- Use of built-in Azure Functions triggers and bindings
- Calls to APIs of underlying Azure services
- Calls to REST endpoints
- Calls to client libraries, packages, or third-party APIs
Following solid error handling practices is important to avoid loss of data or missed messages. Recommended error handling practices include the following actions:
- Enable Application Insights
- Use structured error handling
- Design for idempotency
- Implement retry policies (where appropriate)
Use structured error handling
Capturing and publishing errors is critical to monitoring the health of your application. The top-most level of any function code should include a try/catch block. In the catch block, you can capture and publish errors.
The following triggers have built-in retry support:
By default, these triggers retry requests up to five times. After the fifth retry, both the Azure Queue storage and Azure Service Bus triggers write a message to a poison queue.
You need to manually implement retry policies for any other triggers or bindings types. Manual implementations may include writing error information to a poison message queue. By writing to a poison queue, you have the opportunity to retry operations at a later time. This approach is the same one used by the Blob storage trigger.
Binding error codes
When integrating with Azure services, errors may originate from the APIs of the underlying services. Information relating to binding-specific errors is available in the Exceptions and return codes section of the following articles: