.NET Framework 4.7.1 Web API全局异常处理及堆栈可读性问询

Hey there! Let's tackle your ASP.NET Web API global exception handling and stack trace readability issue step by step.

First, let's fix your incomplete registration code and then enhance the logging to make stack traces far more readable.

Step 1: Complete the ExceptionLogger Registration #

Your WebApiConfig.cs registration snippet was cut off—here's the full, correct way to register your custom MyExceptionLogger:

public static void Register(HttpConfiguration config)
{
    // Web API configuration and services
    // Register your custom ExceptionLogger
    config.Services.Add(typeof(IExceptionLogger), new MyExceptionLogger());

    // Web API routes (keep your existing route setup here)
    config.MapHttpAttributeRoutes();

    config.Routes.MapHttpRoute(
        name: "DefaultApi",
        routeTemplate: "api/{controller}/{id}",
        defaults: new { id = RouteParameter.Optional }
    );
}

Step 2: Enhance Logging for Readable Stack Traces #

The default context.Exception.ToString() dumps all details into a single messy block, which is hard to parse when debugging. Let's modify your MyExceptionLogger to break down exception details clearly—including nested inner exceptions, which are often the root cause of issues.

Here's an improved implementation:

public class MyExceptionLogger : ExceptionLogger
{
    public override void Log(ExceptionLoggerContext context)
    {
        var exception = context.Exception;
        var logBuilder = new StringBuilder();

        // Add request context first (critical for correlating errors to specific API calls)
        logBuilder.AppendLine($"[{DateTime.Now:yyyy-MM-dd HH:mm:ss}] Unhandled API Error:");
        logBuilder.AppendLine($"Request URI: {context.Request.RequestUri}");
        logBuilder.AppendLine($"HTTP Method: {context.Request.Method}");
        logBuilder.AppendLine("----------------------------------------");
        
        // Recursively log the full exception hierarchy
        LogExceptionChain(exception, logBuilder, 0);

        // Write to console error (swap this with your production logging tool later)
        Console.Error.WriteLine(logBuilder.ToString());
    }

    private void LogExceptionChain(Exception ex, StringBuilder sb, int indentLevel)
    {
        var indent = new string('\t', indentLevel);
        sb.AppendLine($"{indent}Exception Type: {ex.GetType().FullName}");
        sb.AppendLine($"{indent}Error Message: {ex.Message}");
        sb.AppendLine($"{indent}Stack Trace:");
        // Indent each line of the stack trace for better alignment
        sb.AppendLine($"{indent}\t{ex.StackTrace.Replace(Environment.NewLine, Environment.NewLine + indent + "\t")}");

        // Log inner exception if it exists (common in nested error scenarios)
        if (ex.InnerException != null)
        {
            sb.AppendLine($"{indent}Inner Exception:");
            LogExceptionChain(ex.InnerException, sb, indentLevel + 1);
        }
    }
}

Key Readability Improvements: #

• Request Context: Adds timestamp, request URI, and HTTP method to help you tie errors directly to specific API requests.
• Hierarchical Indentation: Uses recursion to log inner exceptions with nested indentation, so you can easily follow the chain of errors.
• Formatted Stack Trace: Aligns each line of the stack trace with its parent exception, making it simple to trace the call stack.
• Clear Sectioning: Breaks exception type, message, and stack trace into distinct blocks instead of a single wall of text.

Step 3: Optional (But Recommended) - Use a Production-Grade Logging Framework #

While Console.Error works for development, in production you'll want a robust logging tool like NLog, log4net, or Serilog. These frameworks automatically handle stack trace formatting, support multiple log targets (files, databases, monitoring tools), and let you configure log levels to filter noise.

For example, with Serilog, you could log structured data that makes searching and analyzing errors significantly easier—no more manually parsing plain text logs.

Final Checks #

• Double-check that your MyExceptionLogger is registered correctly in WebApiConfig.cs—this is required for it to catch unhandled exceptions across your entire API.
• Test with different error scenarios (including exceptions with inner exceptions) to verify the log output is clear and captures all critical details.

内容的提问来源于stack exchange，提问作者Sylvain