c# - 更好的 TypeInitializationException(innerException 也为 null)

Question

简介

当用户在 NLog 配置中创建错误(如无效的 XML)时，我们 (NLog) 会抛出一个 NLogConfigurationException。异常包含错误的描述。

但有时如果对 NLog 的第一次调用来自静态字段/属性，则此 NLogConfigurationException 会被 System.TypeInitializationException“吃掉”。

示例

例如如果用户有这个程序:

using System;
using System.Collections.Generic;
using System.Linq;
using NLog;

namespace TypeInitializationExceptionTest
{
    class Program
    {
        //this throws a NLogConfigurationException because of bad config. (like invalid XML)
        private static Logger logger = LogManager.GetCurrentClassLogger();

        static void Main()
        {
            Console.WriteLine("Press any key");
            Console.ReadLine();
        }
    }
}

并且配置中存在错误，NLog 抛出:

throw new NLogConfigurationException("Exception occurred when loading configuration from " + fileName, exception);

但是用户会看到:

“将异常详细信息复制到剪贴板”:

System.TypeInitializationException was unhandled Message: An unhandled exception of type 'System.TypeInitializationException' occurred in mscorlib.dll Additional information: The type initializer for 'TypeInitializationExceptionTest.Program' threw an exception.

所以消息没了!

问题

1. 为什么 innerException 不可见？ (在 Visual Studio 2013 中测试)。
2. 我可以向 TypeInitializationException 发送更多信息吗？喜欢留言？我们已经发送了一个 innerException。
3. 我们可以使用另一个异常吗？或者 Exception 是否有属性以便报告更多信息？
4. 是否有其他方式向用户提供(更多)反馈？

注意事项

• 当然我们对用户编写的程序没有影响。
• 我是 NLog 的维护者之一。
• 你喜欢自己测试吗？结帐https://github.com/NLog/NLog/tree/TypeInitializationException-tester并启动 NLog/src/NLog.netfx45.sln

编辑:

请注意，我是库的维护者，而不是库的用户。 我无法更改调用代码!

Answer 1

我只会指出您在这里处理的潜在问题。您正在与调试器中的错误作斗争，它有一个非常简单的解决方法。使用工具 > 选项 > 调试 > 常规 > 勾选“使用托管兼容模式”复选框。还要取消勾选“仅我的代码”以获得信息最丰富的调试报告:

如果勾选“仅我的代码”，则异常报告的信息量较少，但仍可通过单击“查看详细信息”链接轻松深入了解。

选项名称不必要地含糊不清。它真正所做的是告诉 Visual Studio 使用旧版本的调试引擎。任何使用 VS2013 或 VS2015 的人都会遇到新引擎的问题，可能是 VS2012。这也是之前 NLog 中没有解决这个问题的基本原因。

虽然这是一个很好的解决方法，但并不容易发现。程序员也不会特别喜欢使用旧引擎，旧引擎不支持返回值调试和 64 位代码的 E+C 等 Shiny 的新功能。很难猜测这是新引擎中的一个真正的错误、疏忽还是技术限制。这太丑陋了，所以不要犹豫，将其标记为“错误”，我强烈建议您将其带到 connect.microsoft.com。当它得到修复时，每个人都会领先，我记得至少有一次为此挠头。通过使用 Debug > Windows > Exceptions > 当时打勾的 CLR Exceptions 来深入研究。

这种非常不幸的行为的解决方法肯定是丑陋的。您必须延迟引发异常，直到程序执行进展到足够远为止。我不太了解你的代码库，但延迟解析配置直到第一个日志命令应该处理它。或者存储异常对象并在第一个日志命令中抛出它，可能更容易。