调用 Console.WriteLine(ex.Message) 以防止出现警告消息

发布于 2024-07-26 11:15:41 字数 488 浏览 4 评论 0原文

我们通常在 GUI（表单）等代码的上层捕获异常。

但我通常有这种代码，

try
{
}
catch(Exception ex)
{
  Console.WriteLine(ex.Message);
  MessageBox.Show("Application has encountered error....");
}

我可以在没有标识符的情况下捕获（异常），因为我不需要运行时的消息，但对于调试构建，在 catch 语句处中断肯定很方便。所以我通常会写一个 Console.WriteLine 来防止出现很多未使用的 ex 变量的警告。我的代码中有很多 Console.WriteLine(ex.Message) 的情况。这性价比会降低吗？

注意：更改了标题“Console.WriteLine(ex.Message) 有性能成本吗？” 到“调用 Console.WriteLine(ex.Message) 以防止出现警告消息”

原文

We usually catch exception in the upper level of a code like the GUI (forms).

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?

Note: Changed title from "Does Console.WriteLine(ex.Message) have performance cost?" to "Calling Console.WriteLine(ex.Message) to prevent warning message"

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

玩物 2024-08-02 11:15:41

这是 1 中的多个问题，因此我将尝试展开它：

首先

try{
  ...
}
catch(Exception) 
{
}

是完全有效的语法。添加 Console.WriteLine(ex.Message) 只是为了在没有警告的情况下进行编译，这不是正确的做法。

其次

Console.WriteLine 不是进行诊断的正确方法，请查看 Trace.WriteLine 或更好的日志框架。当然Console.Writeline是有成本的，成本不是太严重，但是调用了，也是有成本的。

第三

有时崩溃更好，它迫使你解决根本问题，至少做一个Debug.Assert 如果发生非常糟糕的情况。

This is a multiple question in 1 so I will try to unroll it:

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.

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.

Thirdly

Sometimes its better to crash, it forces you to fix the root problem, at least do a Debug.Assert if something really bad happens.

回复收藏 0 原文

っ左 2024-08-02 11:15:41

您可以创建一个在调试模式下被过滤掉的扩展方法。

public static Exception
{

    [Conditional("DEBUG")]
    public static void Dump( this Exception ex )
    {
        Console.WriteLine( ex.ToString() );
    }
}

或者甚至更好...

public static Exception
{
    public static void Log( this Exception ex )
    {
#if DEBUG
        Console.WriteLine( ex.ToString() );
#endif
        Logger.WriteLine( ex.ToString() );
    }
}

然后在您的代码中将 Console.WriteLine( ex.ToString() ) 替换为 ex.Log();

但是，通常异常本身会与转储到控制台相比，这更多是一个性能问题。

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();

However, in general the exception itself will be more of a performance issue than dumping to the console.

回复收藏 0 原文

电影里的梦 2024-08-02 11:15:41

更好的选择可能是 System.Diagnostics.Debug.WriteLine( ex ) 或 System.Diagnostics.Trace.WriteLine( ex )。调试仅在定义了 DEBUG 符号时执行某些操作，而跟踪仅在定义了 TRACE 时执行某些操作。默认情况下，您的发布版本将不包含 DEBUG 符号。

回复收藏 0 原文

坠似风落 2024-08-02 11:15:41

一切都会有性能成本。问题是性能成本是否显着。

在这种情况下，我认为更好的问题是 winforms 应用程序中输出的位置，以及为什么只显示 ex.Message 而不是 ex.ToString()。为什么要丢弃信息？

回复收藏 0 原文

删除会话 2024-08-02 11:15:41

为了避免收到警告：在 catch 语句中“声明了变量 'ex' 但从未使用过”，并且
要查看与异常相关的信息，请执行以下操作：

try
{
    ...
}
catch(Exception)    // avoid warning
{
   // set break point inside exception
}

在异常内设置断点并查看调试器变量 $exception
Visual Studio (2008) 中的快速监视窗口、本地窗口或监视窗口。

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:

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).

回复收藏 0 原文