Can I use system err println for debugging in java?

358    Asked by AmyAvery in Java , Asked on Oct 13, 2022

System.err


The "standard" error output stream. This stream is already open and ready to accept output data. Typically this stream corresponds to display output or another output destination specified by the host environment or user. By convention, this output stream is used to display error messages or other information that should come to the immediate attention of a user even if the principal output stream, the value of the variable out, has been redirected to a file or other destination that is typically not continuously monitored.


So, I usually use System.err.println() while debugging (mostly web apps) in my development environment. In most IDEs like Eclipse. System.out and System.err are both print in the same console and since System.err are uniquely highlighted in a different colour (red), I find it easier to print out values using System.err as they are visually highlighted and I don't have to go through the whole log to search for my outputs. This always doesn't require me to start my server in debug mode and for cases where I can just determine looking at certain values that I've outputted and not actually break the execution to inspect for states.


Is this a really bad practice, should I not do it?

It's not a particularly bad habit to have to want to get output when debugging (the worst habit is to not debug).


It's just that we programmers are just so gosh darn lazy. Want output? Look there...

System err println("Got an error: " + e);

That's really easy. You don't need to worry about what logging framework you have, nor what log level it should be at. And this is why we do it all over.

But here's the thing... if you have a project of reasonable size, you have logging in it. If you don't, that's a bad habit. Once you have this logging, and it is something sensible (i.e. not java.util.logging), it's really easy to set up an appender that spits out a standard error.

And to this, there's not really an excuse why not to do it that way.

package c.s.p.m.logging;
import org.apache.log4j.Logger;
public class Main {
    private final static Logger LOG = Logger.getLogger(Main.class);
    public static void main(String[] args) {
        LOG.debug("Oops");
        LOG.info("This is awkward");
        LOG.error("This is bad");
    }
}
and (yep, I'm one of those oddballs that uses the xml format - note that this may not be the optimal one)



   
       
       
           
       
   
   
       
       
       
       
       
       
           
       
   
   
       
       
   
   
       
       
   

and there, in red on my console, I see:
2015-04-30 20:18:34 DEBUG Main:9 - Oops
2015-04-30 20:18:34 INFO Main:10 - This is awkward
2015-04-30 20:18:34 ERROR Main:11 - This is bad

Meanwhile, in my log file:

2015-04-30 20:18:34 ERROR Main:11 - This is bad

The thing is, there's not really an excuse if you've set it up to just use logging. It's a few more lines in the config file for the console appender.

Once you've got that as a habit to set it up, the logger is much better than System.err ever was and you wonder what took you so long to step away from the println. Time stamps, log levels, line numbers... all for free. You'll find yourself stepping away from that console appender too with a little bit of time. You'll have different log files for different classes (and the aggregate log file too) with a log file watcher. You'll debate putting in crazy appenders...

And best of all, no more silly looks from co-workers because you accidentally checked in a System.err.println() that filled up the console in production.

While System.err.println() isn't bad and isn't a habit that you need to break (as long as you make sure you clean up after yourself and wash your hands afterwards), you will find that once you step away from it there are so many better options out there that are even fewer characters to type.



Your Answer

Interviews

Parent Categories