[MUSIC]
Robust code is a style of programming that prevents unexpected actions or
abnormal terminations, unexpected terminations.
It has to handle bad input gracefully.
It has to handle problems in the environment gracefully.
It has to detect internal problems, because programmers make mistakes, and
handle those gracefully.
And if something fails because of input or
an internal problem, it needs to give the user enough information.
So if it was the user's input or something they did,
they can correct it, and if it's not, they are able to give
the people who will fix the program enough information so they know where to look.
And the term fragile means non-robust,
essentially, programming that doesn't do that.
Robust programming has four principles.
The first one is paranoia.
Basically if you don't generate something, don't trust it.
Assume that they really are out to get you.
Very often they won't be, it will just be stupidity or
an inability to read, a failure to read the manuals, or something like that.
But paranoia is a very good thing to think of.
In fact, someone once said that in security, paranoia is not enough.
I'm not sure I agree, but the point is that you need to be suspicious.
The second one is stupidity, which we already mentioned.
Basically, assume the user hasn't read anything,
including how to use the program, and handle cases where the program
is just completely misused, where rather the inputs are bad or things like that.
The third part is dangerous implements.
Don't hand out dangerous implements.
What this basically means is that if a programmer has a view
into the internals of a library, or
a user has a view into the internals of how the program does things, they may make
changes that affect the consistency of the data within the program.
So if you have routine A,
followed by routine B, B may make certain assumptions about the output of A.
If the programmer can access the data that's being passed,
then he or she can cause problems.
More critically, if within a function in the library,
the data structures allow the programmer to take actions that would affect the data
structure, or rather affect the data in the data structure, then
the programmer can change things in a way that will make the internals inconsistent.
And you want to prevent that.
Finally, one of the most common errors a programmer will make is to say,
well, this can't happen.
The usual response is, want to bet?
Because even where things seem like they can't happen, Someone in the future,
other than the programmer who wrote it, may be maintaining the program.
And so he or she might add code that will do what the original programmer said could
never happen.
So it's good to check for that, and you'll see a few examples of this later on.