These two are just examples as you said. In fact, all non-functional requirments of that sort can potentially conflict with each other. In the book "Building Evolutionary Architectures" there is a table of roughly a hundred of these "-ilities" (as they are also often called).
It is sort of an exercise for software architects to consider the potential conflict between any two of these. You can basically decide on which of these are important to your projects, then keep track of these conflicts.
To get back to your precise example and take a look at the definition of the term robustness in Wikipedia:
In computer science, robustness is the ability of a computer system to cope with errors during execution[1][2] and cope with erroneous input.
As you can see from the definition, robustness involves errors. On the other hand, you want to have correctness, which basically means the absence of errors.
To make the conflict more apparent, let's consider a simple input field. From the correctness requirement it's easiest for any erroneous input made by the user to be rejected. But robustness requires you to be able to work with this input, which may not be entirely correct.
To bring it all around to your book: what is the acceptable trade-off now? Let's say you write a scientific application in which the user can input a voltage amount, including the magnitude. So correct inputs would be something like "10 kV" or "200 mV". Acceptable trade-offs may include allowing inputs like "10kV", "10kVolt", or even just "10" and for the sake of correctness map these to a valid voltage value. Note that this is still a trade-off and not a "best-of-both-worlds" thing. Consider upper-case vs lower-case: "10 kV" and "10 KV" might be fine, but "10 mV" and "10 MV" may not be. Correctness becomes questionable as you are not sure if it's milli or mega now, but if you insist on the right upper/lower-casing you lose out on robustness again, because some erroneous inputs won't work.
