You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Learn how to handle errors and retry events in Azure Functions, with links to specific binding errors, including information on retry policies.
@@ -20,22 +20,22 @@ This article describes general strategies for error handling and the available r
20
20
21
21
Errors that occur in an Azure function can come from:
22
22
23
-
- Use of built-in Functions [triggers and bindings](functions-triggers-bindings.md).
24
-
- Calls to APIs of underlying Azure services.
25
-
- Calls to REST endpoints.
26
-
- Calls to client libraries, packages, or third-party APIs.
23
+
- Use of built-in Functions [triggers and bindings](functions-triggers-bindings.md)
24
+
- Calls to APIs of underlying Azure services
25
+
- Calls to REST endpoints
26
+
- Calls to client libraries, packages, or non-Microsoft APIs
27
27
28
28
To avoid loss of data or missed messages, it's important to practice good error handling. This table describes some recommended error-handling practices and provides links to more information.
29
29
30
30
| Recommendation | Details |
31
31
| ---- | ---- |
32
-
|**Enable Application Insights**| Azure Functions integrates with Application Insights to collect error data, performance data, and runtime logs. You should use Application Insights to discover and better understand errors that occur in your function executions. To learn more, see [Monitor Azure Functions](functions-monitoring.md). |
32
+
|**Enable Application Insights**| Azure Functions integrates with Application Insights to collect error data, performance data, and runtime logs. You should use Application Insights to discover and better understand errors that occur in your function executions. To learn more, see [Monitor executions in Azure Functions](functions-monitoring.md). |
33
33
|**Use structured error handling**| Capturing and logging 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 log errors. For information about what errors might be raised by bindings, see [Binding error codes](#binding-error-codes). Depending on your specific retry strategy, you might also raise a new exception to run the function again. |
34
34
|**Plan your retry strategy**| Several Functions bindings extensions provide built-in support for retries and others let you define retry policies, which are implemented by the Functions runtime. For triggers that don't provide retry behaviors, you should consider implementing your own retry scheme. For more information, see [Retries](#retries).|
35
35
|**Design for idempotency**| The occurrence of errors when you're processing data can be a problem for your functions, especially when you're processing messages. It's important to consider what happens when the error occurs and how to avoid duplicate processing. To learn more, see [Designing Azure Functions for identical input](functions-idempotent.md). |
36
36
37
37
>[!TIP]
38
-
> When using output bindings, you aren't able to handle errors that occur when accessing the remote service. Because of this, you should validate all data passed to your output bindings to avoid raising any known exceptions. If you must be able to handle such exceptions in your function code, you should access the remote service by using the client SDK instead of relying on output bindings.
38
+
> When using output bindings, you aren't able to handle errors that occur when accessing the remote service. Because of this behavior, you should validate all data passed to your output bindings to avoid raising any known exceptions. If you must be able to handle such exceptions in your function code, you should access the remote service by using the client SDK instead of relying on output bindings.
39
39
40
40
## Retries
41
41
@@ -63,10 +63,10 @@ The following table indicates which triggers support retries and where the retry
63
63
64
64
Azure Functions lets you define retry policies for specific trigger types, which are enforced by the runtime. These trigger types currently support retry policies:
Retry support is the same for both v1 and v2 Python programming models.
@@ -80,9 +80,9 @@ The retry policy tells the runtime to rerun a failed execution until either succ
80
80
A retry policy is evaluated when a function executed by a supported trigger type raises an uncaught exception. As a best practice, you should catch all exceptions in your code and raise new exceptions for any errors that you want to result in a retry.
81
81
82
82
> [!IMPORTANT]
83
-
> Event Hubs checkpoints aren't written until after the retry policy for the execution has completed. Because of this behavior, progress on the specific partition is paused until the current batch is done processing.
83
+
> Event Hubs checkpoints aren't written until after the retry policy for the execution finishes. Because of this behavior, progress on the specific partition is paused until the current batch is done processing.
84
84
>
85
-
> The version 5.x of the Event Hubs extension supports additional retry capabilities for interactions between the Functions host and the event hub. For more information, see `clientRetryOptions` in the [Event Hubs host.json reference](functions-bindings-event-hubs.md#host-json).
85
+
> The version 5.x of the Event Hubs extension supports extra retry capabilities for interactions between the Functions host and the event hub. For more information, see `clientRetryOptions` in the [Event Hubs host.json reference](functions-bindings-event-hubs.md#host-json).
86
86
87
87
### Retry strategies
88
88
@@ -98,7 +98,7 @@ The first retry waits for the minimum delay. On subsequent retries, time is adde
98
98
99
99
---
100
100
101
-
When running in a Consumption plan, you are only billed for time your function code is executing. You aren't billed for the wait time between executions in either of these retry strategies.
101
+
When running in a Consumption plan, you're only billed for time your function code is executing. You aren't billed for the wait time between executions in either of these retry strategies.
102
102
103
103
### Max retry counts
104
104
@@ -347,17 +347,17 @@ public void run(
347
347
348
348
When you're integrating with Azure services, errors might originate from the APIs of the underlying services. Information that relates to binding-specific errors is available in the "Exceptions and return codes" sections of the following articles:
![prmerger-automator[bot]](https://avatars.githubusercontent.com/u/22479449?v=4&size=40){kind=avatar}
0 commit comments