I was playing Family Feud with @tgiannowho has hooked me on this online game yesterday when the following message was displayed.
The programmer in me was amused as anyone who codes has experienced these moments when things don’t go as planned. It happens to everyone who writes software. It occurred to me that this would be an awesome example in the Computer Science classroom demonstrating that it can happen to the best of us. @alfredtwo, who had thought that he wouldn’t blog yesterday did blog about it.
His takewas on the situation involved the types of error messages that coders can provide (it reminded me of this resource of the best 404 web page missing pages) and also the importance of proper communication in the Computer Science classroom. If you are a teacher of Computer Science, Alfred’s post provides some good thoughts for lesson design about the topic.
There are also a couple of other takes on this that I think are important for discussion with students.
Condition and Exception Checking
This is always a tough topic to deal with in the classroom because it can lead to some tedious programming. I can remember trying to drill these points home.
- If you are expecting a number between 1 and 10 as user input, then it’s your job as programmer to test their response and make sure that it’s valid and re-prompt if it isn’t. To the novice programmer, it may seem like a make-work project to keep the user on the straight and narrow but it’s important. I think the relevance is increasingly important with portable devices, smaller keys, and the increased chances of error on input;
- No matter what you’re doing, you cannot allow the user or your program to divide by zero;
- If you’re looking for numeric input, it had better be numeric because only numbers can be used for calculations;
- Keep the robot on the carpet!
- and so on…
Test, Test, Test
But, sir, it works.
When you design a problem for solution, you normally give an example of what might be entered as input and the expected output as a result of processing those inputs. You don’t typically give all possibilities for input as examples. In fact, part of the academics behind programming is trying to determine every conceivable action that a user might take. My rule of thumb was that as much time should be devoted to testing it as was involved in developing it. We would also test each other’s programs to see if we could break it. That’s what many users will do.
Those darned users.
But, this isn’t just academia. Family Feud is a serious activity to the end user. (well to me anyway) There are more serious examples to be give though. Take a wander through this Wikipedia article about Buffer Overruns. It’s pretty heady stuff but takes what might otherwise seem like yet another assignment and puts it into a real world context.
Who would have thought that you could milk so much from an error message? It’s all important and those students who are in your Computer Science class may be writing your next favourite app.