It's UWAweek 25 (mid-year break)


This forum is provided to promote discussion amongst students enrolled in Open Source Tools and Scripting.

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.

How do I ask a good question?
Displaying selected article
Showing 1 of 439 articles.
Currently 5 other people reading this forum.

 UWA week 15 (1st semester, week 6) ↓
SVG not supported

Login to reply


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

Cheers MichaelW 👨‍🎨

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  5:07AM Sep 06 2023
Privacy policy