Week 12 Discussion — Fail Loudly or Fail Silently? — Traditional alternative (no AI)
Instructors: publish this instead of the adaptive version if you prefer, and unpublish or delete the adaptive one.
Hook
A program that meets a bad line of data has two choices: stop with an error, or catch the problem and keep going. This week you saw both. A bike-share report that met the text n/a caught the ValueError, printed skipped n/a, and still added up the good docks to 13. A reading-log program with a bare except: printed could not add the log, and the real problem, a NameError from a misspelled name, stayed hidden. Catching an error can keep a program useful, and it can also bury the one message that would have told you what was wrong.
Your discussion question — choose Option A or Option B; they carry the same weight and the same rubric, and you say which you picked.
Option A: A program reads a file of daily entries, and one line holds text that is not a number. Pick one setting from your own life, major, or workplace where such a program might run, such as a step counter, a lab's sample log, or a shop's order file, and take a position on whether the program should stop with an error or skip the bad line and keep going. Use this week's ideas (exception, try statement, except block, exception type) and say what someone who weighs speed and transparency differently from you would argue.
Option B: A bare except: makes a program that never crashes, and it also hides typos and other real bugs. Pick one kind of program you use or could imagine writing and take a position on when, if ever, catching every exception is the right call, and when the program should name the type it expects and let every other error stop it loudly. Use this week's ideas (bare except, exception type, traceback, the save-and-reload pattern) and say what someone who weighs convenience and honesty about errors differently from you would argue.
There is no single right answer. People who agree on every fact about what try and except do still disagree about when a program should keep going quietly, because those questions rest on judgment about who reads the output and what a missed error costs them, as well as on the facts about Python. Pick the option you actually care about, and make your case.
Expectations
Activity format: one initial post followed by two substantive peer replies. Plan on about 45 minutes across the two deadlines; your instructor sets both due dates in Canvas.
Your initial post — by the first due date (early in the module week):
- Say which option you chose.
- For Option A, name the setting, describe in words the program that reads the file, and say whether it should stop with an error or skip the bad line, and why; for Option B, name the kind of program, say when if ever it should catch every exception, and say which type it should name instead.
- Use at least two of this week's terms (exception, try statement, except block, exception type, bare except) correctly.
- State the strongest case for a view you do not hold, in one or two sentences.
- Never paste real files or records that belong to other people; describe them in your own words.
- Length: roughly 150–250 words if written. You may instead record your post as audio or video (about two minutes) and attach a transcript; both forms are scored by the same rubric.
Your replies — by the second due date (the end of the module week):
- Reply substantively to at least two classmates.
- A substantive reply does more than agree: run a short try statement on a bad line like the one in their post and report which block ran, name someone their position could leave without a warning, or make the strongest fair case for the side they did not take. "Nice point!" on its own does not count.
What a strong post looks like:
I chose Option A. A community garden keeps a file of how many volunteers came each day, and a short program adds the days up for a monthly thank-you note. If one line says n/a, I think the program should catch the ValueError, skip that line, and print which line it skipped, because a thank-you note is not worth stopping for. I would not use a bare except, because it would also hide a typo in my own code. Someone could argue that a total missing a day is wrong and nobody will notice the skipped line, and that is fair, so I would print the skipped line at the top of the report where a person reads it.
Notice how it names the setting, describes what the program does with the bad line, takes a position with a reason, names who reads the output, and states a fair case for the other side. That is the bar.
Participation rubric
This discussion is worth 10 points. The three criteria below look at your initial post and your peer replies.
| Criterion | Full credit | Partial credit | No credit |
|---|---|---|---|
| Quality of the initial post (4 pts) | A specific setting or kind of program, a description of what it does with a bad line or a missing file, a clear position with a reason, and a fair statement of another view | A setting is present, but the program stays vague, or the position is asserted without a reason | Missing, off-topic, or no reasoning about how a program should handle an error |
| Use of course concepts (3 pts) | Uses exception, try statement, except block, exception type, and bare except precisely, with every claim about which block runs matching a run | Uses a term loosely, or says a try statement catches every error | No course terms, or used incorrectly |
| Engagement with peers (3 pts) | Two or more substantive replies that extend or challenge a classmate's reasoning | One substantive reply, or replies that only agree | No replies, or "I agree" with nothing added |
Post early if you can — the best threads happen when people have time to reply before the second due date.
Built with The Course Maker · samples.thecoursemaker.com