为什么System.Exception.ToString不为内部异常调用虚拟ToString? [英] Why doesn't System.Exception.ToString call virtual ToString for inner exceptions?
问题描述
这是.NET的 System.Exception.ToString 的实际来源:
This is the actual source for .NET's System.Exception.ToString:
public override string ToString()
{
return this.ToString(true, true);
}
private string ToString(bool needFileLineInfo, bool needMessage)
{
string str1 = needMessage ? this.Message : (string) null;
string str2 = str1 == null || str1.Length <= 0 ? this.GetClassName() : this.GetClassName() + ": " + str1;
if (this._innerException != null)
str2 = str2 + " ---> " + this._innerException.ToString(needFileLineInfo, needMessage) + Environment.NewLine + " " + Environment.GetRuntimeResourceString("Exception_EndOfInnerExceptionStack");
string stackTrace = this.GetStackTrace(needFileLineInfo);
if (stackTrace != null)
str2 = str2 + Environment.NewLine + stackTrace;
return str2;
}
除了非常丑陋之外，还可以注意到对于所有内部异常，私有，非虚拟的ToString将被称为.换句话说，如果您在异常中重载了 ToString ，则如果您的异常恰好是嵌套的，则不会被调用.哦，等等，原来内置的异常也有同样的问题，例如 System.IO.FileNotFoundException 打印出文件的路径-它不是消息的一部分:
Apart from the sheer ugliness, one can notice that for all inner exceptions the private, non-virtual ToString will be called. In other words, if you overload ToString in your exception it won't get called if your exception happens to be nested. Oh, hold on, turns out built-in exceptions have same problems, e.g. System.IO.FileNotFoundException prints out path of the file - it is not a part of the Message:
public override string ToString()
{
string str = this.GetType().FullName + ": " + this.Message;
if (this._fileName != null && this._fileName.Length != 0)
str = str + Environment.NewLine + Environment.GetResourceString("IO.FileName_Name", new object[1]
{
(object) this._fileName
});
...
}
但是，如果包装一个实例...除非您自己遍历异常树并检测异常的类型或自己调用 ToString 并进行一些普通的解析，否则这些信息将丢失.
But if you wrap an instance... this information will be lost, unless you traverse the exceptions tree yourself and detect exceptions' type or call ToString yourself and do some mundane parsing.
这是一个烦人的麻烦，使日志记录/写入错误对话框丢失信息或容易出错.有趣的是， Mono正确了.
That's an annoying inconvenience, making logging/writing error dialogs either lose information or being bug-prone. Interestingly, Mono gets it right.
.NET版本中是否存在任何隐藏的智慧?
Is there any hidden wisdom in .NET's version?
这不是基于意见的问题.虽然我觉得这种设计选择很烦人，但我想知道这种方法的好处.设计新解决方案时了解它们可能会有所帮助.
this is not opinion based question. While I find this design choice annoying, I would like to know the benefits of this approach. Knowing them may be beneficial when desiging new solutions.
推荐答案
Exception.ToString()不应呈现给用户.它应该在日志文件中呈现给开发人员.
Exception.ToString() is not something that should be presented to users. It is something that should be presented to developers, perhaps in a log file.
ToString()的默认实现通常执行正确的事情".请注意，它如何处理嵌套异常，多个异常(例如 AggregateException 或 SqlException )，甚至跨远程边界的异常.尝试使用XML序列化器对XML进行反序列化时遇到错误，您将非常感谢它为您提供了多少信息-通常足以直接指向异常原因.
The default implementation of ToString() normally does the "right thing". Notice how it does handle nested exceptions, and multiple exceptions (like AggregateException or SqlException), and even exceptions across a remoting boundary. Try getting an error during the deserialization of XML with the XML serializer, and you'll really appreciate how much information it gives you - usually enough to point directly to the cause of the exception.
如果您希望看到某些特定的显示内容，则应就此问题与Microsoft合作.特别是，您不太可能让他们简单地调用覆盖的ToString.显然，该不想.但是，如果您的ToString想要显示某些内容而不显示给他们，请与他们交谈，看看是否还有另一种解决方法，或者在将来的发行版中它们是否可以做.
If there is something specific that you would like to see displayed, then you should engage Microsoft on this issue. In particular, you're not likely to get them to simply call your overridden ToString. Clearly, the do not want to. However, if there is something your ToString wanted to display that theirs does not, then talk to them and see if there's another way to go about it, or if there's something they can do in a future release.
这篇关于为什么System.Exception.ToString不为内部异常调用虚拟ToString?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
