Please consider offering answers and suggestions to help other students!
And if you fix a problem by following a suggestion here,
it would be great if other interested students could see a short
"Great, fixed it!" followup message.
Hi Everyone,
This is in response to some questions I was asked in the lab.
What if the user types male rather than the expected Male?
My attitude to error handling is quite pragmatic:
Is there a sensible interpretation of the input data that is close to what is expected? I think you'd agree that there is no ambiguity between male and Male, so both should be accepted, while mal or Mal should not be. (Otherwise, we're getting into the realm of the infamous phone spelng corrector.
If the user input does not make sense in the context, it is better to halt the computation than continue, and potentially produce rubbish. It is also important to also let the user know what is happening via an informative error message. Use common sense for that "informative" means, but you'd agree that ERROR is not acceptable (for a range of reasons).
Why use /dev/stderr?
It is good style to separate "good" output i.e. that conforms to the specification and user expectations, from process or error output, which the user has no interest in, e.g. progress, error messages, etc. Of course, the user can readily combine the two streams, but then it'll be their choice, but if you combine the two streams, it may muddle things up entirely for the user. Yes, ordinary output could be sent to /dev/stdout, but that is not required (and looks odd).