Both related to this request
https://feedback.azure.com/admin/v3/suggestions/20308660/
And the fact that people today using bindings aren't able to catch an exception from something like an output binding in the context of the language worker.
For what it's worth I really like the asp.net core filter approach to handling exceptions globally though I can see the merit of another function being triggered providing enough context is available to it.
@alexjamesbrown
Function filters have a pretty big flaw in that you can't modify the output of the function. E.g. in the case of an http triggered function, you can't decide what status code to return based on the exception caught in the filter.
@mayoatte * currently have a pretty big flaw
Hopefully this (eventually) gets some traction https://github.com/Azure/azure-webjobs-sdk/issues/1314
... although it's almost 2 years old :(
Can durable be the answer here?
https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-error-handling
We can consider using Durable Functions if we want to handle errors with functions other than Http Trigger.
But, Http Trigger functions that require synchronization are difficult to use with Durable Functions.
In particular, there are very many scenarios in which the content formed when Http Trigger Functions encounter an exception is returned.
So I want to give priority to the HttpTrigger function to handle global error handling.
Any update about this topic?
What is the strategy used to provide always the same Http Response structure when errors occur on HttpTriggers?
We are also interested in figuring out a way to catch all errors (ie if a function times out). Then we would like to log these errors with some custom scope atttibutes set (servicename , payload identifier, +++). In the absence of a catchall method defined for exceptions - does anyone have a suggestion on how to achieve this?
We too need this..
I need this as well.
That would be a very useful feature.
+1 from my side for the feature.
Most helpful comment
Any update about this topic?
What is the strategy used to provide always the same Http Response structure when errors occur on HttpTriggers?