Home > Enterprise >  Where do error logs in Console output come from even though I did not implement a logging statement
Where do error logs in Console output come from even though I did not implement a logging statement

Time:07-26

I have various .NET 6.0 web applications running in Docker containers. I use Serilog as logging library built with builder.Host.UseSerilog() and then use Microsoft.Extensions.Logging.ILogger<out TCategoryName> in my classes injected via dependency injection. If an unhandled error occurs and I did not implement a logging statement at this point nevertheless an error message comes up in the Docker logs of that container. Where does this message come from? As it is not formatted like the normal Serilog outputs it seems like it is anything built in .NET. Is there any way to redirect these messages, e.g. log them into a database or send them via a HTTP Post to another service?

It is the same with a very simple console application:

namespace ConsoleApp1;

internal class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello, World!");
        throw new InvalidOperationException("Hello, World as error");
    }
}

Where does the following output come from? And is there any way to handle that message without try catch and log them manually at any possible error occurrence?

Unhandled exception. System.InvalidOperationException: Hello, World as error
   at ConsoleApp1.Program.Main(String[] args) in C:\Users\Admin\source\repos\ConsoleApp1\ConsoleApp1\Program.cs:line 8

CodePudding user response:

Where does the following output come from?

You had an unhandled exception in your program. This means that you allowed an exception to bubble up and out of your application, so the dotnet runtime was forced to handle it for you.

Just like the Console.WriteLine() command, the runtime will dump unhandled exception messages to STDOUT.

is there any way to handle that message without try catch and log them manually at any possible error occurrence?

I'd really advice using try/catch - that's what it's designed to do. It allows you time to think about the design of your app and allows you to do all the custom logic you want when handling very precise errors.

John Wu also suggests the AppDomain.UnhandledException Event, however that's more or less equivalent to "put a try/catch around your entire application and call it a day".

The doc's example is:

using System;

public class Example
{
   public static void Main()
   {
      AppDomain currentDomain = AppDomain.CurrentDomain;
      currentDomain.UnhandledException  = new UnhandledExceptionEventHandler(MyHandler);

      try {
         throw new Exception("1");
      } catch (Exception e) {
         Console.WriteLine("Catch clause caught : {0} \n", e.Message);
      }

      throw new Exception("2");
   }

   static void MyHandler(object sender, UnhandledExceptionEventArgs args)
   {
      Exception e = (Exception) args.ExceptionObject;
      Console.WriteLine("MyHandler caught : "   e.Message);
      Console.WriteLine("Runtime terminating: {0}", args.IsTerminating);
   }
}
// The example displays the following output:
//       Catch clause caught : 1
//
//       MyHandler caught : 2
//       Runtime terminating: True
//
//       Unhandled Exception: System.Exception: 2
//          at Example.Main()
  • Related