为什么大多数例外都会忽略特定于实例的信息？答案

【问题标题】：Why do most exceptions omit instance-specific information?为什么大多数例外都会忽略特定于实例的信息？
【发布时间】：2011-12-12 15:28:57
【问题描述】：

我注意到大多数异常消息不包含特定于实例的详细信息，例如导致异常的值。他们通常只会告诉您错误的“类别”。

例如，当尝试使用 3rd 序列化对象时。派对图书馆，我收到了带有消息的 MissingMethodException：

“没有为此对象定义无参数构造函数。”

在很多情况下这已经足够了，但通常（通常在开发过程中）类似

的消息

“没有为这个'Foo'类型的对象定义无参数构造函数。”

可以通过直接引导您找到错误原因来节省大量时间。

InvalidArgumentException 是另一个例子：它通常告诉你参数的名称，而不是它的值。大多数框架引发的异常似乎都是这种情况，但也适用于 3rd 方库。

这是故意的吗？

暴露内部状态（如变量的“错误”值）是否存在安全隐患？

【问题讨论】：

【解决方案1】：

我能想到的两个原因：

首先，引发异常的参数可能是一个值，它是传递给公共接口的参数的处理形式。如果不花时间重新抛出一个在大多数情况下都相同的异常，那么这个值可能没有意义。

其次，更重要的是，确实存在安全风险，这可能很难事后猜测（如果我正在编写一个通用容器，我不知道它会是什么上下文中使用）。如果我们能提供帮助，我们不希望“Credit-Card: 5555444455554444”出现在错误消息中。

最终，最有用的调试信息会因错误而异。如果类型、方法和（如果可能的话）文件和行号还不够，是时候编写一些调试代码来捕获您想要知道的内容，而不是在下次您抱怨它还没有被捕获时可能需要不同的信息（实例的字段状态可能与参数一样有用）。

【讨论】：

关于您的第三点：有时应用程序会通过堆栈跟踪“调用 home”，我见过文件名/行号让您摸不着头脑的情况。在这些情况下，了解导致错误的值可能很有用，但我同意安全风险绝对不值得。
@FrancescoDeVittori “打电话回家”是一件令人讨厌的事，我更经常认为这是一个缺陷。理想情况下，应该向公共成员抛出异常，但如果适用，请包含一个 InnerException ，详细说明更深层次的错误，以防错误所在。当然，如果您认为您的公共成员不可能抛出，那么您就不会这样做（再说一次，如果您这么认为，那么要么是您的错误而不是调用者的错误，要么是调用者的错误加上您的你如何处理他们的错误的错误）。

【解决方案2】：

InvalidArgumentException 和（根据@Ian Nelson）“在字典中找不到键”都有一些共同点——不能保证框架能够找到合适的值来显示——如果键/参数是任何用户定义的类型，并且 ToString() 没有被覆盖，那么你只会得到类型名称 - 它不会增加很多价值。

【讨论】：

【解决方案3】：

异常主要是供程序使用的。大多数程序不知道如何处理有关实例的信息。

Message 属性是针对人类消费的。除了在调试场景中，人类不知道如何处理Foo。

【讨论】：

除调试场景外，人类不知道“没有为此对象定义无参数构造函数”的含义。
好的，但大多数异常消息不会按原样呈现给最终用户。在不调试时，它们通常会被丢弃或包装到错误报告/日志/等中。对于用户而言，KeyNotFoundException 也不比 'Foo' 更有意义。

【解决方案4】：

许多异常机制试图通过传递单个异常派生对象来满足正交目的的大杂烩：

不幸的是，我不知道任何广泛使用的异常机制实际上可以完成上述所有五个。

【讨论】：