[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.