Allow uncaught exceptions to "trigger" another function for global exception handling

[jeffhollan]

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.

[simonvane]

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]

Or this https://github.com/Azure/azure-webjobs-sdk/wiki/Function-Filters

[oluatte]

@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.

[alexjamesbrown]

@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 :(

[mhoeger]

Can durable be the answer here? https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-error-handling

[yuka1984]

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.

[joaoantunes]

Any update about this topic? What is the strategy used to provide always the same Http Response structure when errors occur on HttpTriggers?

[markusfoss]

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?

[dominicusmento]

We too need this..

[EliPulsifer]

I need this as well.

[thomashanke]

That would be a very useful feature.

[Sandeep7OnShell]

+1 from my side for the feature.

[wboevink]

Really could use this, noticed that some exceptions don't show up in logs or application insights.

[elahmo]

Any updates in 2021 about this?

I was really sad to see there is no proper way to handle this with Azure functions in C#. In my previous project we used Sentry to log everything, including unhandled exceptions so I was hoping to have something here, as debugging and investigating issues with dozens of functions can be really hard, but it seems there is no viable approach to address this other than adding sentry handler in each except block.

[jordan-cote]

+1 This should be a priority considering the basic-ness of this feature.

[dominicusmento]

I'm afraid that it won't be seen in azure functions on dotnet core 3.x.

However, on .net5 , using dotnet-isolated, it's possible to use custom middleware for that purpose. Microsoft docs Re[mark]able blog - azure functions middleware

There are still some challenges on how to return status code 500 when using it but it seems there are some workarounds: discussion