更好的TypeInitializationException(innerException也为null) [英] Better TypeInitializationException (innerException is also null)

问题描述

简介

当用户在NLog的配置中创建错误时(例如无效的XML)，我们(NLog)会抛出NLogConfigurationException.异常中包含错误说明.

When an user creates a mistake in the configuration of NLog (like invalid XML), We (NLog) throw a NLogConfigurationException. The exception contains the description what is wrong.

但是，如果第一次调用NLog来自静态字段/属性，则有时NLogConfigurationException被System.TypeInitializationException吃掉".

But sometimes this NLogConfigurationException is "eaten" by a System.TypeInitializationException if the first call to NLog is from a static field/property.

示例

例如如果用户有此程序:

E.g. if the user has this program:

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抛出:

and there is a mistake in the config, NLog throws:

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

但是用户会看到:

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

"Copy exception details to the clipboard":

System.TypeInitializationException未处理 消息:mscorlib.dll中发生了类型为'System.TypeInitializationException'的未处理异常 附加信息:"TypeInitializationExceptionTest.Program"的类型初始值设定项引发了异常.

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. 还有另一种向用户提供(更多)反馈的方法吗?

1. Why is innerException not visible? (tested in Visual Studio 2013).
2. Can I send more info to the TypeInitializationException? Like a message? We already sending an innerException.
3. Can we use another exception or are there properties on Exception so that more info is reported?
4. Is there another way to give (more) feedback to the user?

注释

• 当然，我们对用户编写的程序没有影响.
• 我是NLog的维护者之一.
• 您想自己测试吗?结帐 https://github.com/NLog/NLog/tree/Type/InitializationException-tester并启动NLog/src/NLog.netfx45.sln

• of course we have no influence on the program written by the user.
• I'm one of the maintainers of NLog.
• Do you like to test it by yourself? Checkout https://github.com/NLog/NLog/tree/TypeInitializationException-tester and start NLog/src/NLog.netfx45.sln

修改:

请注意，我是图书馆的维护者，而不是图书馆的用户. 我无法更改呼叫代码！

please note that I'm the library maintainer, not the user of the library. I cannot change the calling code!

推荐答案

在这里，我仅指出您要处理的潜在问题.您正在解决调试器中的一个错误，它有一个非常简单的解决方法.使用工具>选项>调试>常规>选中使用托管兼容模式"复选框.还要取消选中我的代码"以获取最有用的调试报告:

I'll just point out the underlying problem you are dealing with here. You are fighting a bug in the debugger, it has a very simple workaround. Use Tools > Options > Debugging > General > tick the "Use Managed Compatibility Mode" checkbox. Also untick Just My Code for the most informative debugging report:

如果勾选了我的代码"，则异常报告的信息较少，但仍可以通过单击查看详细信息"链接轻松地进行追溯.

If Just My Code is ticked then the exception report is less informative but still can be drilled down easily by clicking the "View Detail" link.

选项名称不必要是神秘的.它真正做到的是告诉Visual Studio使用旧版本的调试引擎.使用VS2013或VS2015的任何人在使用新引擎(可能是VS2012)时都会遇到此问题.也是以前在NLog中未解决此问题的基本原因.

The option name is unnecessarily cryptic. What it really does is tell Visual Studio to use an older version of the debugging engine. Anybody that uses VS2013 or VS2015 will have this trouble with the new engine, possibly VS2012. Also the basic reason that this issue did not have be addressed in NLog before.

虽然这是一个很好的解决方法，但并不容易发现.程序员也不会特别喜欢使用旧引擎，旧引擎不支持闪亮的新功能，例如返回值调试和用于64位代码的E + C.这到底是新引擎中的错误，疏忽还是技术限制，很难猜测.这太丑陋了，因此不要犹豫将其标记为"bug"，我强烈建议您将此代码连接到connect.microsoft.com.修复后，每个人都将领先于我，至少记得一次，我为此挠了挠头.依次使用调试">"Windows">异常">勾选的CLR异常对其进行深入研究.

While this is a very good workaround, it is not exactly easy to discover. Nor would programmers particularly like to use the old engine, shiny new features like return value debugging and E+C for 64-bit code are not supported by the old engine. Whether this is a truly a bug, an oversight or a technical limitation in the new engine is hard to guess. This is excessively ugly so don't hesitate to label it "bug", I strongly recommend you take this to connect.microsoft.com. Everybody will be ahead when it gets fixed, I scratched my head over this at least once that I remember. Drilled it down by using Debug > Windows > Exceptions > ticked CLR Exceptions at the time.

这种非常不幸的行为的变通办法一定很丑陋.您必须延迟引发异常，直到程序执行进度足够长为止.我对您的代码库不太了解，但是将解析配置延迟到第一个日志记录命令应该处理完为止.或存储异常对象并将其放在第一个log命令上，可能会更容易.

A workaround for this very unfortunate behavior is sure to be ugly. You do have to delay raising the exception until program execution has progressed far enough. I don't know your codebase well enough, but delaying parsing the config until the first logging command ought to take care of it. Or store the exception object and throw it on the first log command, probably easier.

这篇关于更好的TypeInitializationException(innerException也为null)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！