Why use stderr when printf works fine?

Question

Why should we use stderr when printing a custom error message from printf works fine?

For example why use stderr at all when I can just write a statement like this:

    printf("error! you didn't... blah blah blah");

Answer 1

It is good practice to redirect all error messages to stderr, while directing regular output to stdout. It is beneficial to do this because anything written to stderr is not buffered, i.e., it is immediately written to the screen so that the user can be warned immediately.

Answer 2

stderr stands for standard error stream.

In console programming it is the console -- the screen. It is essentially the same as stdout.

The general practice is to redirect all error messages to stderr and all regular output to stdout.

The reason is that it is possible to redirect standard output to a file instead of the screen. So If you perform a dir > dirlist.txt command on command prompt the directory listing goes into the text file instead of screen. If you code to redirect error messages to stderr, the error will always go to the screen instead of the file so that the user could be warned immediately instead of ending up seeing unexpected results in the file.

using printf() will display the error message to console which will be stored in the stdout buffer , but using stderr , it is different

stderr can be used as an argument for any function that takes an argument of type FILE* expecting an output stream, like fputs or fprintf.

Although in many cases both stdout and stderr are associated with the same output device (like the console), applications may differentiate between what is sent to stdout and what to stderr for the case that one of them is redirected. For example, it is frequent to redirect the regular output of a console program (stdout) to a file while expecting the error messages to keep appearing in the console.

It is also possible to redirect stderr to some other destination from within a program using the freopen function.

stderr is is never fully buffered on startup. It is library-dependent whether the stream is line buffered or not buffered by default (see setvbuf).

Answer 3

It is a good practice.

Lets say you use linux. If so, you can run your program following way:

./program >out 2>errout

'out' file will contain only STDOUT.
'errout' file will contain only STDERR

So if your output is hundreds of lines long, it is easier to look for few errors in 'errout' rather than look through tons of non-error lines combined with error lines.

Answer 4

If you redirect your program's output into a file you still would want to see the errors on screen.

Answer 5

In addition to stderr not being buffered, it is also nice to split output into errors vs. normal output to allow other programs to use of your program more easily. That way, the calling program can redirect standard or error output selectively depending on what it needs to know. This same facility can be used manually through Unix shells - here's one way I use that sometimes:

% find / -iname hello.txt
find: /.DocumentRevisions-V100: Permission denied
find: /.fseventsd: Permission denied
find: /.MobileBackups: Permission denied
find: /.Spotlight-V100: Permission denied
find: /.Trashes: Permission denied
^C
% find / -iname hello.txt 2>/dev/null <-- filter "Permission denied" errors