16

I have Azure Function (Http trigger) that can fail. I also have Application Insights configured for it.

In case of error (Which is better):

  1. Catch exception, wrap with more info and rethrow it. (Sends 500 response) OR
  2. Catch exception, log it, wrap it, rethrow it to caller. (Sends 500 response) OR
  3. Catch exception, log it (Don't throw it), Manual send 500 response.

Application Insight is able log exceptions. I don't really see point in logging error and throwing exception at the same time.

What are the guidelines? What is good practise?

Hooch
  • 28,817
  • 29
  • 102
  • 161
  • There are two articles on Exception handling I link often and consider required reading: https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/ | https://www.codeproject.com/Articles/9538/Exception-Handling-Best-Practices-in-NET | Web Errors tend to be on the "Exogenous" part of the spectrum, from the first article. | If (and when) you should wrap is discussed in the 2nd. – Christopher Nov 12 '19 at 13:16
  • I remember a recent question where wrapping was helpfull. We got an IOException, with message that was clearly from a Argument Exception (function parameter is null or some such). So it likely wrapped around the original ArgumentException. It did add "Syntactic value", because now I knew the Argument Exception happened soemwhere *in the IO code*. – Christopher Nov 12 '19 at 13:19
  • Hooch, what's your preferred aproach at the moment? Let Function app infrastructure log raised exception into connected AppInsights? – dbardakov Oct 26 '20 at 12:47

1 Answers1

2

From my experience which is building an HTTP triggered azure function with Python, I noticed that: When handling exceptions and then manually return something to the client you do have control over the function returned value but the framework marks the function's job as 'Succeeded', which then makes it more difficult to be tracked & monitored in the Application Insights.

For your question, I ended up with a catch clause that mixes 1 & 3 i.e a hybrid approach where I try to identify the origin of the exception, then for exceptions from my code I'm wrapping it and return 500, and for other exceptions that originated from code that I'm using I re-throw them and let the azure function framework return a 500 and to mark the function's job as 'Failed'.

ben cohen
  • 21
  • 2