调试:使用 System.out.println() 或不使用 System.out.println()

发布于 2024-10-10 04:54:03 字数 107 浏览 0 评论 0原文

这是我的问题。更具体地说,我正在尝试习惯 Eclipse 的调试器,并且我想知道在某些情况下是否仍然会打印到控制台,或者是否认为这是一种应该完全避免的不良做法。另外,什么可以被认为是整体调试的好方法?

That is my question. More specifically, I'm trying to get used to Eclipse's debugger and I'd like to know if printing to console is still done in some cases or if it's considered a bad practise that should be entirely avoided. Also, what can be considered as good approach(es) to debugging overall?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(5

宫墨修音 2024-10-17 04:54:03

请改用 System.err.println() 。

为什么?

System.out.println() 通常会重定向到文件或其他输出,而这几乎总是打印在控制台上。它更容易调试,也是正确的方法。


编辑(警告:主观):

既然您询问是否应该完全避免 System.out.println:我不相信您必须始终的任何事情 避免使用 goto、蓝屏死机或其他任何情况导致计算机崩溃。有时,您只需要一种快速而肮脏的方法来快速完成小事情,而这显然不值得您花 1 小时来尝试以“正确的方式”做事”的方式,而不是 5 分钟的修复,无论“好”方式有多好。在决定是否应该使用某些东西时,请使用您的判断,但永远不要为自己设定规则,例如“我永远不会使用 goto!”。 :)

编辑 2(示例):

假设您正在调试崩溃的驱动程序,并且您怀疑正在执行不应该执行的 if 语句。无需花费三个小时来了解如何使用 ZwRaiseHardError 来显示消息框,只需在 if 中调用 KeBugCheck 即可让该死的系统崩溃。当然,您会重新启动,但除非重新启动需要几个小时,否则您就节省了那么多时间。

Use System.err.println() instead.

Why?

System.out.println() is often redirected to a file or another output, while this is pretty much always printed on the console. It's easier for debugging and also the right way to do it.


Edit (warning: subjective):

Since you asked about whether System.out.println should be entirely avoided: I don't believe in anything that you must always avoid, be it using goto's, crashing your computer with a BSOD, or whatever. Sometimes you just need a quick-and-dirty way to get small things done fast, and it just plain isn't worth the 1 hour you'll spend on it to try to do things the "right" way, instead of a 5-minute fix, no matter how good the "good" way is. Use your judgment when deciding if something should be used or not, but never set rules for yourself like "I'll never use goto!". :)

Edit 2 (example):

Let's say you're debugging a crashing driver and you suspect that an if statement that shouldn't be execute is being executed. Instead of spending three hours finding out how to use ZwRaiseHardError to display a message box, just call KeBugCheck inside the if and crash the darned system. Sure, you'll reboot, but unless your reboot takes hours, you just saved yourself that much time.

窗影残 2024-10-17 04:54:03

最好的选择是日志库(当然,这会为您的项目添加额外的依赖项)。例如,查看公共日志记录。
主要优点是您可以在 DEBUG 级别编写调试消息,并且在部署代码时,您只需将记录器配置为跳过这些消息(而不是在代码中搜索所有出现的 System.out.println) 。
另一大优点是记录器通常可以配置为在任何地方写入(甚至发送电子邮件或短信),而无需接触您的代码。

The best choice would be a logging library (of course, this adds an extra dependency to your project). Check out commons-logging, for instance.
The main advantage is that you can write your debug messages in the DEBUG level and when you deploy your code, you'll just configure the logger to skip those messages (instead of searching for all occurrences of System.out.println in your code).
One other great advantage is that loggers usually can be configured to write anywhere (even send email messages or SMS) also without touching your code.

ゞ花落谁相伴 2024-10-17 04:54:03
  1. 小点:如果您的程序实际上通过 System.out 向控制台输出有用的内容,您可能需要将调试信息打印到 System.err

  2. 您通常应该努力进行尽可能多的调试(理想情况下使用一些标准记录器,例如 log4j)。这既可以简化您实际开发程序时的调试,也可以更轻松地调试生产中已发布的代码。好处是您的代码保持不变,并且不需要添加 debugf 打印,但默认情况下,日志记录配置可以关闭日志记录,直到实际需要为止(或至少降低日志级别)

  3. 到目前为止作为一般简单的“将 println 扔到墙上”调试,它有时可能是最快的调试方法之一,尽管它绝不应该是唯一/主要的方法。

    为什么它有用?除其他原因外,因为在调试器中运行 Java 程序可能比在调试器之外慢得多;或者因为您的错误出现在无法在 Eclipse 调试器中轻松复制的环境/情况中。

  1. Minor point: if your program actually outputs something useful to the console via System.out, you may want to instead print the debugging info to System.err

  2. You should generally strive to have as much debugging as possible (ideally using some standard logger like log4j). This both eases debugging when you're actually developing the program AND allows for much easier debugging of already-released code in production. The benefit is that your code remains unchanged and you don't need to ADD debugf prints, yet by default the logging config can turn off the logging until it's actually needed (or at least turn down the level of logs)

  3. As far as general simple "throw printlns at the wall" debugging, it can sometimes be one of the fastest ways to debug, though it should by no means be the only/main one.

    Why can it be useful? Among other reasons, because running a Java program in a debugger may be much slower than outside of it; or because your bug manifests in an environment/situation that can't be easily replicated in your Eclipse debugger.

时光匆匆的小流年 2024-10-17 04:54:03

如果修复错误后调试打印行不会保留在代码中,那么请执行对您来说最简单的操作。 Lambert 建议使用 System.err.println() 是个好主意,因为您可以将其与程序可能产生的其他输出区分开来。如果调试打印行将保留在您的代码中,那么我建议使用 log4j 等日志记录框架。这样,您可以根据您是尝试调试某些内容还是只是在生产中运行来提高或降低输出级别。使用 log4j 时请确保以正确的级别输出内容。不要只在 INFO 中记录所有内容。

If the debugging print lines are not going to stay in the code after you've fixed your bug, then do whatever is easiest for you. Lambert's advice of using System.err.println() is a good idea since you can differentiate it from other output that your program may produce. If the debugging print lines are going to stay in your code, then I would advise on using a logging framework like log4j. This way you can dial up or down the level of output based on whether you're trying to debug something or just running in production. Be sure to output things at the right level when using log4j. Don't just log everything at INFO.

江城子 2024-10-17 04:54:03

我使用 System.out.println 进行调试,以防出现问题或通知我方法已开始确保一切正常工作,但当我发布程序时,我总是将其删除,因为它减慢程序速度。

I use System.out.println for my debugging in case i have a problem or to inform me that methods have started to make sure everything has worked properly but when I publish the program I always remove it because it slows down the program.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文