Q:

What defines robust code?

My professor keeps referring to this Java example when he speaks of "robust" code:
if (var == true) {
    ...
} else if (var == false) {
    ...
} else {
    ...
}

He claims that "robust code" means that your program takes into account all possibilities, and that there is no such thing as an error - all situations are handled by the code and result in valid state, hence the "else".
I am doubtful, however. If the variable is a boolean, what is the point of checking a third state when a third state is logically impossible?
"Having no such thing as an error" seems ridiculous as well; even Google applications show errors directly to the user instead of swallowing them up silently or somehow considering them as valid state. And it's good - I like knowing when something goes wrong. And it seems quite the claim to say an application would never have any errors.
So what is the actual definition of "robust code"?

A:

what is the point of checking a third state when a third state is
  logically impossible?

What about a Boolean? that allows for a NULL state that is neither true nor false.  Now what should the software do?  Some software has to be highly crash-resistant like pacemakers.  Ever seen someone add a column to a database that was a Boolean and initialize the current data to NULL initially?  I know I've seen it.
Here are a few links that discuss what it means to be robust in terms of software:

Robust Programming
Robust Definition
Robustness, the forgotten code quality.
How to write robust code

If you think there is one universally agreed upon definition of "robust" here, good luck.  There can be some synonyms like bomb-proof or idiot-proof.  The Duct Tape Programmer would be an example of someone that usually writes robust code at least in my understanding of the terms.

A:

For the sake of my discussion a Bool can have 2 states, True or False. Anything else is non-conformance to the programming langugae specification. If your tool chain is non-conformant to its specification, you are hosed no matter what you do. 
If a developer created a type of Bool that had more than 2 states, it's the last thing he would ever do on my codebase. 
Option A.
if (var == true) {
    ...
} else if (var == false) {
    ...
} else {
    ...
}

Option B
if (var == true) {
    ...
} else {
    ...
}

I assert Option B is more robust.....
Any twit can tell you to handle unexpected errors. They are usually trivally easy to detect once you think of them. The example your professior has given is not something that could happen, so it's a very poor example. 
A is impossible to test without convoluted test harnesses. If you can't create it, how are you going to test it? If you have not tested the code, how do you know it works? If you don't know it works, then you are not writing robust software. I think they still call that a Catch22 (Great movie, watch it sometime).
Option B is trivial to test.  
Next problem, ask you professor this question "What do you want me to do it about it if a Boolean is neither True nor False?" 
That should lead into an a very interesting discussion..... 
Most cases, a core dump is approriate, at worst it annoys the user or costs a lot of money.  What if, say, the module is the Space shuttle realtime reentry calculation system? Any answer, no matter how inaccurate, cannot be worse than aborting, which will kill the users. So what to do, if you know the answer might be wrong, go for the 50/50, or abort and go fo the 100% failure. If I was a crew member, I'd take the 50/50. 
Option A kills me
Option B gives me an even chance of survival. 
But wait - it's a simulation of the space shuttle reentry - then what? Abort so you know about it. Sound like a good idea? - NOT - because you need to test with the code you plan to ship.   
Option A is better for simluation, but can't be deployed. It's useless
Option B is the deployed code so the simulation performs the same as the live systems. 
Let's say this was a valid concern. The better solution would be to isolate the error handling from the application logic. 
if (var != true || var != false) {
    errorReport("Hell just froze over, var must be true or false")
}
......
if (var == true){
 .... 
} else {
 .... 
}

Futher reading - Therac-25 Xray machine, Ariane 5 Rocket failure and others
(Link has many broken links but enough info that Google will help) 

A:

Actually your code is not more robust but LESS robust. The final else is simply dead code that you can't test.
In critical software such as in spacecrafts, dead code and more generally untested code is forbidden: If a cosmic ray produces a single event upset that in turn makes your dead code being activated, anything is possible. If the SEU activates a portion of robust code, the (unexpected) behaviour stays under control.

