To err is human, to stderr divine

Ajouté : 2026-06-03

[00:00:00]Where do you send your errors? Today we're talking about standard error, which is something that new programmers are often not aware of. And even when they discover it, a lot of people just don't use it. So, I thought today we should talk about it. Also, most of you are probably watching this video on YouTube, but those of you on Patreon noticed that this video showed up a few days early. I wanted to let you know just as a way to say thank you to all of you who helped make this channel possible on Patreon. I'm going to be posting videos a few days early. I haven't decided just how early, but you know, a few days before they go live on YouTube, they will show up on Patreon.

[00:00:33]Adree as always, just to say thank you.

[00:00:35]I really appreciate the financial support that so many of you contribute to make this channel possible. So anyway, let's jump into the code. So anyway, what is standard error? Well, on nearly all modern operating systems, so that's Linux, Mac OS, Windows, BSD, etc., when a new process is created, it starts with three open pipes. It has standard in coming in and it has coming out, standard out and standard error.

[00:01:05]Now standard in that's for passing input into the process. Standard out is for output from that process. So if we are let's say we write hello world here and we just say print f hello world. When we do this we are writing to standard out.

[00:01:21]So, let's just also not forget to return. Exit success. Okay. And I have a simple make file here. Just like in most of my other programs, I like to have a make file to compile things. Check out my make videos if you are new to make files. But so, yeah. So, if we come down here and compile it, I forgot the f in print f. Sorry about that. But now, if we run it, we just wrote hello world to standard out. But then there's standard error. Now standard error is an output pipe just like standard out but it's there specifically for error outputs. So for example let's change this up a little and let's say we're taking in arguments and we say like so we have arg c and arg v. Okay so this is going to take in some arguments and let's say we're going to do something with those arguments. So maybe I'll come down here and say print f arg number one equals okay. So we'll just print it out for now, but we could it could be anything.

[00:02:14]Whatever we were whatever we're doing with this argument and then print out arg v1. Now that's fine. But if we're going to do this, we should probably now check to see if the user forgot the argument. Right? That would be the most obvious error here. If I try to compile it and then we run it without an argument, we're going to get null. And that's probably not what we intended. So we would come up here and we would add an error check something like if arg c is not equal to two which is what we expect then we would have some kind of call like to frrint f and we can write to standard error here and we could say error you missed the argument and then let's return exit failure. If you've watched very many of my videos, you have seen me do this kind of check before. Sometimes I've sent it to standard error and sometimes I've just used print f to send it all to standard out. Today I want to talk about why you might not want to do that. But if we come down here and we compile our code again, then we can run it now. It's going to say error, you missed the argument. And if we do have an argument like Jacob, then it's going to print out that arg one equals Jacob. And at this point, we can't really tell the difference between the output that is produced when the process is successful.

[00:03:32]So that's hello world, and the output that's produced because of an error because both standard out and standard error are both being sent to the terminal. They're ending up in the same place. And so you think, well, what was the point of separating them? This seems kind of pointless. But really, it's not pointless because it makes it really easy later on if we decide we want to separate these two cases. is if we want to handle errors one way and regular output the other. So let's just say for example, let's say that I am running this program, right? I am going to run this program, but instead of just printing the output to the terminal like this, I would like to pipe its output into the standard in of another process.

[00:04:10]So like let's just use WC. This is a useful little terminal program that counts the characters, words, and lines in its input. So the pipe character here is just going to connect our example program's output, its standard out to the standard in of WC. And so now when it runs we can see that WC is reporting that there were two lines six words and 26 characters. But what if we let's say what if we forgot the argument right? So we have an error case that happens here.

[00:04:39]Well in this case I don't want my error messages to be passed to WC. I want to make sure that I see the error messages so that I can then go fix them. Because if it just gets passed to WC, WC might report one line and I'm like, "Oh, wait.

[00:04:54]Did my program maybe my program can print one line and it's totally legitimate." And that's what this separation gives us. See, in this case, we're piping standard out, but standard error stays in the terminal. So, we can see the error message and that can be really helpful. And of course, there are other ways we could handle this. We could redirect errors and normal output to different processes or to different files. It really depends on the behavior that's going to be the most convenient for us. But the point of this video at least is that if you separate your output and your errors, sending one to standard out and one to standard error, it is going to give you a lot more flexibility later on with what you do with that program when it's running. And so, my friends, it's worth getting into the habit of separating your output and your errors. Even on programs where you think, ah, I'm never going to need to separate the output, it's still a good idea. You might think it doesn't matter.

[00:05:42]Someday you'll thank me for it. See you.