locked
Send notification with an unhandled exception RRS feed

  • Question

  • Hi

    We are planing to move our WCF services to service fabric, currently have a custom solution where if an  unhandled exception happens an email (using smtp) is send to the developer team, we are using IServiceBehavior, IOperationBehavior and IOperationInvoker for this.

    I'm assuming there is a better way to do this in azure, or maybe its just a configuration setting in the azure portal, anyone has a better idea on how to implent this.

    Thanks for your time

    Tuesday, September 6, 2016 4:46 PM

Answers

  • It's pretty complicated situation we find, Service Fabric Runtime is designed to use ETW and we preferred Contextual Logging (Serilog) so we ended up writing a ETW listener which post everything to Serilog so we had everything in one place.

    In terms of catching exceptions we made a mistake of catching, logging and NOT re-throwing, this stopped SF from doing it's thing of re-starting services after fatal errors so we had to go back and fix it up.

    Tuesday, September 13, 2016 5:22 PM

All replies

  • I might let all services throw any unhandled and catch them in the web api layer with exception filter. Something like:

    public static class WebApiConfig
    {
       
    public static void Register(HttpConfiguration config)
       
    {
           
    <mark>config.Filters.Add(new ProductStore.NotImplExceptionFilterAttribute());</mark>

           
    // Other configuration code...
       
    }
    }

    Wednesday, September 7, 2016 12:05 AM
  • We dont stop the exception, we just catch them to log some context data and then throw it again (without losing the context for the client).

    We just need a mechanism to let our developer know that an exception happened.

    Monday, September 12, 2016 6:53 PM
  • It's pretty complicated situation we find, Service Fabric Runtime is designed to use ETW and we preferred Contextual Logging (Serilog) so we ended up writing a ETW listener which post everything to Serilog so we had everything in one place.

    In terms of catching exceptions we made a mistake of catching, logging and NOT re-throwing, this stopped SF from doing it's thing of re-starting services after fatal errors so we had to go back and fix it up.

    Tuesday, September 13, 2016 5:22 PM