In this lesson we'll learn how to exit a program using the std::process
module in Rust and it's exit()
method.
Why is only now that we don't need to make the variable mutable and not assign an initial value? Wouldn't that be possible as soon as we introduced match
in previous lessons?
Hey Leonel!
That's a good question. We couldn't make it just let a:u32;
before, because in case the parse()
would fail, there would be a chance for a
to be uninitialized, which the compiler doesn't allow (you can try it yourself).
However, after we've introduced the process::exit()
, a
can only have one possible value at runtime, which is the one that is assign when parse()
was successful. If it wasn't successful, the entire program would stop.
The compiler is smart enough to understand that there'd be practically only one assignment/initialization at runtime, which is why a
doesn' t have to be mutable anymore.
Surprising, I know! Didn't expect the compiler to be this smart either haha.
I'm sure this is its own deep dive, but I noticed that the error code supplied doesn't appear in the program output, so what is its point? I gathered from the video that the number chosen for the error code is arbitrary, rather than some preset that taps into and/or triggers existing Rust functionality. Knowing from your previous comments that you can run different versions of the binary, e.g. debug, which might have additional output, my guess is that the idea is to let you give a unique ID (i.e. the error code) to each exit condition and then be able to tell what exactly triggered the exit.
Hi Matt,
I'm sure this is its own deep dive, but I noticed that the error code supplied doesn't appear in the program output, so what is its point?
Right, so passing the error code to exit()
isn't suppose make it output the error code on screen. Rather, it should be treated as a signal. Any error code that is not 0
is considered an error. So for example, when you write a program and have another program consume that first program, receiving a signal of non-zero tells you that the program has failed. OTOH, if your program fails and doesn't propagate an exit code that's equal to or higher than 1
, the calling program will think it was successful.
Also notice that this is not a Rust specific thing, but rather how processes signal their status to other processes in operating systems:
https://bencane.com/2014/09/02/understanding-exit-codes-and-how-to-use-them-in-bash-scripts/
So for example, when you write a program and have another program consume that first program, receiving a signal of non-zero tells you that the program has failed. OTOH, if your program fails and doesn't propagate an exit code that's equal to or higher than
1
, the calling program will think it was successful.
I see; that's a context that I was totally missing. Thanks, it makes sense now. That article about Bash scripts was fascinating and very illuminating.