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
Copy file name to clipboardExpand all lines: articles/azure-functions/functions-bindings-error-pages.md
+19-24Lines changed: 19 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ Handling errors in Azure Functions is important to help you avoid lost data, avo
14
14
This article describes general strategies for error handling and the available retry strategies.
15
15
16
16
> [!IMPORTANT]
17
-
> Preview retry policy support for all triggers other than Timer, Kafka, and Event Hubs was removed in December 2022. For more information, see the [Retries](#retries) section. Retry policies for supported triggers is now generally available (GA).
17
+
> Preview retry policy support for certain triggers was removed in December 2022. Retry policies for supported triggers is now generally available (GA). For a list of extensions that currently support retry policies, see the [Retries](#retries) section.
18
18
19
19
## Handling errors
20
20
@@ -27,21 +27,12 @@ Errors that occur in an Azure function can come from:
27
27
28
28
To avoid loss of data or missed messages, it's important to practice good error handling. This section describes some recommended error-handling practices and provides links to more information.
29
29
30
-
### Enable Application Insights
31
-
32
-
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).
33
-
34
-
### Use structured error handling
35
-
36
-
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).
37
-
38
-
### Plan your retry strategy
39
-
40
-
Several Functions bindings extensions provide built-in support for retries. In addition, the runtime lets you define retry policies for Timer, Kafka, and Event Hubs-triggered functions. To learn more, see [Retries](#retries). For triggers that don't provide retry behaviors, you might want to implement your own retry scheme.
41
-
42
-
### Design for idempotency
43
-
44
-
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).
30
+
| Recommendation | Details |
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). |
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
+
|**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 infiormation, see [Retries](#retries).|
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). |
45
36
46
37
## Retries
47
38
@@ -54,14 +45,16 @@ The following table indicates which triggers support retries and where the retry
| RabbitMQ |[Binding extension](functions-bindings-rabbitmq-trigger.md#dead-letter-queues)|[Dead letter queue](https://www.rabbitmq.com/dlx.html)|
62
-
| Azure Service Bus |[Binding extension](../service-bus-messaging/service-bus-dead-letter-queues.md)|[Dead letter queue](../service-bus-messaging/service-bus-dead-letter-queues.md#maximum-delivery-count)|
| Service Bus |[Binding extension](functions-bindings-service-bus-trigger.md)|[host.json](functions-bindings-service-bus.md#hostjson-settings)<sup>*</sup> |
<sup>*</sup>Requires version 5.x of the Azure Service Bus extension. In older extension versions, retry behaviors are implemented by the [Service Bus dead letter queue](../service-bus-messaging/service-bus-dead-letter-queues.md#maximum-delivery-count).
65
58
66
59
### Retry policies
67
60
@@ -81,7 +74,7 @@ Retry policies aren't supported in version 1.x of the Functions runtime.
81
74
82
75
The retry policy tells the runtime to rerun a failed execution until either successful completion occurs or the maximum number of retries is reached.
83
76
84
-
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 rethrow any errors that you want to result in a retry.
77
+
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.
85
78
86
79
> [!IMPORTANT]
87
80
> 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.
@@ -102,6 +95,8 @@ The first retry waits for the minimum delay. On subsequent retries, time is adde
102
95
103
96
---
104
97
98
+
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.
99
+
105
100
#### Max retry counts
106
101
107
102
You can configure the maximum number of times that a function execution is retried before eventual failure. The current retry count is stored in memory of the instance.
0 commit comments