C# 调用 Console.WriteLine(ex.Message) 以防止出现警告消息
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1056324/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Calling Console.WriteLine(ex.Message) to prevent warning message
提问by Nap
We usually catch exception in the upper level of a code like the GUI (forms).
我们通常在 GUI（表单）等代码的上层捕获异常。
But I usually have this kind of code
但我通常有这种代码
try
{
}
catch(Exception ex)
{
Console.WriteLine(ex.Message);
MessageBox.Show("Application has encountered error....");
}
I could just catch(Exception) without the identifier because I do not need the message on runtime, but for the debugging build, it sure is convenient to break at the catch statement. So I usually write a Console.WriteLine to prevent a lot of warning of unused ex variable. I have a lot of case of Console.WriteLine(ex.Message) in my code. Does this cost performance decrease?
我可以在没有标识符的情况下使用 catch(Exception) ，因为我不需要运行时的消息，但是对于调试构建，在 catch 语句处中断确实很方便。所以我通常会写一个 Console.WriteLine 来防止很多未使用的 ex 变量的警告。我的代码中有很多 Console.WriteLine(ex.Message) 案例。这个性价比会下降吗？
Note: Changed title from "Does Console.WriteLine(ex.Message) have performance cost?" to "Calling Console.WriteLine(ex.Message) to prevent warning message"
注意：将标题从“Console.WriteLine(ex.Message) 是否有性能成本？”更改为标题。到“调用 Console.WriteLine(ex.Message) 以防止警告消息”
采纳答案by Sam Saffron
This is a multiple question in 1 so I will try to unroll it:
这是 1 中的多个问题，因此我将尝试展开它：
Firstly
首先
try{
...
}
catch(Exception)
{
}
Is perfectly valid syntax. Adding a Console.WriteLine(ex.Message) just to get the thing to compile without warning is not the right thing to be doing.
是完全有效的语法。添加一个 Console.WriteLine(ex.Message) 只是为了在没有警告的情况下编译东西并不是正确的做法。
Secondly
其次
Console.WriteLine is not the proper way to do diagnostics, look at Trace.WriteLine or better still a Logging framework. Of course Console.Writeline has a cost, the cost is not too serious, nonetheless a call is made, and it has a cost.
Console.WriteLine 不是进行诊断的正确方法，请查看 Trace.WriteLine 或更好的Logging framework。当然Console.Writeline是有成本的，成本不算太高，不过打个电话，也是有成本的。
Thirdly
第三
Sometimes its better to crash, it forces you to fix the root problem, at least do a Debug.Assertif something really bad happens.
有时崩溃会更好，它会迫使您解决根本问题，如果真的发生了不好的事情，至少做一个Debug.Assert。
回答by John Saunders
Everything has a performance cost. The question is whether the performance cost is significant.
一切都有性能成本。问题是性能成本是否显着。
In this case, I think the better questions are where the output is going in a winforms application, and why you're only displaying ex.Message and not ex.ToString(). Why throw away information?
在这种情况下，我认为更好的问题是输出在 winforms 应用程序中的位置，以及为什么只显示 ex.Message 而不是 ex.ToString()。为什么要丢弃信息？
回答by Brian Reiter
A better choice might be System.Diagnostics.Debug.WriteLine( ex ) or System.Diagnostics.Trace.WriteLine( ex ). Debug only does something if the DEBUG symbol is defined and Trace only does something is TRACE is defined. By default your release build will not include the DEBUG symbol.
更好的选择可能是 System.Diagnostics.Debug.WriteLine( ex ) 或 System.Diagnostics.Trace.WriteLine( ex )。Debug 仅在定义了 DEBUG 符号的情况下执行某些操作，而 Trace 仅在定义了 TRACE 的情况下执行某些操作。默认情况下，您的发布版本将不包含 DEBUG 符号。
回答by Paul Alexander
You can create an extension method that gets filtered out in debug mode.
您可以创建一个在调试模式下被过滤掉的扩展方法。
public static Exception
{
[Conditional("DEBUG")]
public static void Dump( this Exception ex )
{
Console.WriteLine( ex.ToString() );
}
}
Or even better...
或者更好...
public static Exception
{
public static void Log( this Exception ex )
{
#if DEBUG
Console.WriteLine( ex.ToString() );
#endif
Logger.WriteLine( ex.ToString() );
}
}
Then in your code replace Console.WriteLine( ex.ToString() )to ex.Log();
然后在您的代码中替换Console.WriteLine( ex.ToString() )为ex.Log();
However, in general the exception itself will be more of a performance issue than dumping to the console.
但是，一般来说，异常本身比转储到控制台更像是一个性能问题。
回答by Kenny Mann
In C# there is cost which is not insignificant when catching an exception. Test it for yourself, write something like this:
在 C# 中，捕获异常时的开销并非微不足道。自己测试一下，写成这样：
- Create a list of strings
- In this list, make 25% of them a number and the rest a single letter.
- Run a for loop going through each list and doing a int foo = (int)myList[0] but wrap it in try/catch.
- 创建字符串列表
- 在此列表中，将其中的 25% 设为数字，其余设为单个字母。
- 运行 for 循环遍历每个列表并执行 int foo = (int)myList[0] 但将其包装在 try/catch 中。
Bump up the rate to 50%, then 75%, then 100%. The 100% will be slightly slower, but not by much.
将比率提高到 50%，然后是 75%，然后是 100%。100% 会稍微慢一点，但不会慢很多。
In this particular example, the real world answer would be to use Int32.TryParse instead, but this shows you the penalty.
在这个特定的例子中，现实世界的答案是改用 Int32.TryParse，但这会向你展示惩罚。
回答by Zamboni
To avoid getting the warning: "The variable 'ex' is declared but never used" in a catch statement, and also to see the information associated with the exception, do the following:
为避免在 catch 语句中收到警告：“变量 'ex' 已声明但从未使用过”，并查看与异常相关的信息，请执行以下操作：
try
{
...
}
catch(Exception) // avoid warning
{
// set break point inside exception
}
Set a break point inside the exception and look at the debugger variable $exception in either the quick watch window, locals window, or watch window inside Visual Studio (2008).
在异常内设置一个断点，并在 Visual Studio (2008) 中的快速监视窗口、本地窗口或监视窗口中查看调试器变量 $exception。
