Debugging: before System.out.println () or not for System.out.println ()

Question

This is my question. In particular, I am trying to get used to the Eclipse debugger, and I would like to know if console printing will still be done in some cases or if it believes that bad practice should be completely eliminated. Also, what can be considered a good approach (s) to debugging in general?

Answer 1

A better choice would be a library of journals (of course, this will add extra dependency to your project). For example, you can register a commercial registration. The main advantage is that you can write your debugging messages at the DEBUG level, and when you deploy the code, you simply configure the logger to skip these messages (instead of looking for all occurrences of System.out.println in your code). Another great advantage is that registrars can usually be configured to record anywhere (even send emails or SMS) without affecting your code.

Answer 2

Use System.err.println() instead.

Why?

System.out.println() often redirected to a file or other output, while it is often printed to the console. This is easier to debug, and also the right way to do it.

---

Edit (warning: subjective):

Since you asked whether System.out.println should be completely excluded: I don’t believe in anything that you should always avoid, whether using goto, crashing your computer with BSOD or something else, sometimes you just need to a quick and dirty way to quickly do small things, and it’s just not worth the 1 hour you spend on it to try to do something the “right” way, and not a 5-minute fix, no matter how good the “good” one is Method: Use your opinion when deciding whether to use something or not, but no yes no set rules for yourself, like "I'll never use a goto!". :)

Change 2 (example):

Say you are debugging a crash driver and you suspect that an if being executed that should not be executed. Instead of spending three hours on how to use ZwRaiseHardError to display a message box, just call KeBugCheck inside the if and trigger the black system. Of course, you will reboot, but if your reboot does not take many hours, you just saved yourself so much time.

Answer 3

• Minor point: if your program really outputs something useful to the console through System.out, you can instead print debugging information to System.err

• As a rule, you should strive to have as much debugging as possible (ideally, use some standard logger, for example log4j ). This makes debugging easier when you are actually developing a program. And it can greatly simplify debugging of already released code in production. The advantage is that your code remains the same and you do not need to debug ADD debugf, but by default the logging configuration can turn off logging until it is needed (or at least reduce the level of logs)

• As for the general simple “drop println on the wall”, it can sometimes be one of the fastest ways to debug, although it should by no means be the only / main one.

  Why might this be helpful? Among other reasons, since running a Java program in the debugger can be much slower than outside it; or because your error appears in an environment / situation that cannot be easily replicated in your Eclipse debugger.

Answer 4

If the print debugging lines do not remain in the code after fixing your error, do everything that will be easier for you. Lambert advises using System.err.println () is a good idea, since you can distinguish it from another result that your program can produce. If print debugging lines remain in your code, I would recommend using a logging framework like log4j for example. In this way, you can type or lower the output level based on whether you are trying to debug something or just run in production. Be sure to output data at the right level when using log4j. Don't just register everything with INFO.

Answer 5

I use System.out.println for my debugging in case I have a problem or tell me that the methods have started to check that everything works correctly, but when I publish the program, I always delete it because it slows down the program.