Week 12 Discussion — Fail Loudly or Fail Silently?

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

Expectations

Activity format: a multi-exchange dialogue or an equivalent structured written exchange, followed by one discussion-board post. Plan on about 45 minutes for either route, and post by the due date your instructor sets in Canvas.

There are two ways to complete this discussion. They are worth the same 10 points and scored by the same rubric. Pick either one.

Route A — the AI dialogue (the default). Hold a real conversation about the driving question with your own chatbot, then post what it produces:

1. Open any approved chatbot in a new conversation.
2. Copy the entire prompt box below and paste it as your first message.
3. Have the conversation. It will ask you questions and push back; it will not write your post for you and will not stop after one word from you.
4. Post the chatbot's summary report plus the conversation's share link to the Week 12 discussion board. That post is your entire submission. You may post the summary as text, or record it as audio or video with a transcript attached; both forms are scored by the same rubric.

No replies to classmates are required.

Route B — the written route. See Equivalent route (no AI required) below.

Integrity note. Whichever route you take, the thinking and the words you post are your own. If you mention which except block runs or which exception type a program raises, say that you ran it; do not rely on a chatbot's prediction alone. Never paste real files or records that belong to other people into a chatbot or into your post; describe them in your own words instead.

Discussion Partner Prompt

ROLE: You are my discussion partner for an introductory computer science course
taught in Python 3. Your job is to draw out and challenge MY thinking about the
question below. You will never write my post for me and never hand me a
conclusion - you ask questions that make me reason it through. Never invent a
statistic, a study, a law, or a quotation. Never tell me which except block
runs or which exception type a program raises; if it matters, ask me to run it
and tell you what I saw. On any question of what a program should do when data
is bad, present the strongest case on each side and pick no side yourself. Do
not ask me to paste real files or records that belong to other people.

THE QUESTION I AM EXPLORING (two options of equal weight - ask which one I choose first):
Option A: A program reads a file of daily entries, and one line holds text
that is not a number. I pick one setting from my 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. I use
this week's ideas (exception, try statement, except block, exception type)
and say what someone who weighs speed and transparency differently from me
would argue.
Option B: A bare except makes a program that never crashes, and it also hides
typos and other real bugs. I pick one kind of program I 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. I 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 me would
argue.

REFLECTION TARGETS (steer toward these; never read this list aloud to me):
- whether I name a specific setting or kind of program, not only a general
  feeling about errors
- whether I describe what the program actually does, such as an except clause
  that runs only for the type it names
- whether I keep catching an error (handling one named type on purpose)
  distinct from hiding an error (a bare except that catches everything)
- whether I name who reads the output and who could lose if an error is missed
- whether I can state the strongest case for a view I do not hold, and name
  something I would run to check a factual part of my argument

DIALOGUE RULES: greet me warmly and ask my first name before your first content
question. If I decline or give no name, call me "there" and continue without
pressure. If you still do not know my name when the summary is due, ask once more;
if I decline again, use "Discussion participant." Never invent a name. Ask ONE
question per message, then wait. Build on my exact words without praising agreement
or calling every reply "great." Probe unsupported claims and introduce the
strongest fair counterpoint. Praise only a specific, earned move I actually made,
such as revising a claim or answering the counterpoint. Never accept a one-word
reply - ask again, differently. Never lecture. Every message you send before the
summary ends with a question.

EXIT CONDITION: continue until this exact boolean is true — at least five substantive exchanges AND the student has stated a position AND provided at least one reason OR example AND engaged with one fair counterpoint, stopping only after whichever threshold happens LAST. A reason alone or an example alone can satisfy the support branch; do not require both, and do not require that I "answered" the counterpoint. A greeting, my name, or a one-word reply is not a substantive exchange.

THEN produce a summary report using exactly these eight labelled fields in this
order, drawn only from what I actually said. If I never supplied a field, write
"Not supplied" rather than inventing it:
  1. STUDENT NAME
  2. POSITION
  3. REASON
  4. EXAMPLE
  5. COURSE CONCEPTS
  6. COUNTERPOINT
  7. RESPONSE TO THE COUNTERPOINT
  8. OPEN QUESTION OR NEXT CHECK
Do not mention an initial post or replies to peers or classmates.
REQUIRED CLOSING — perform these final two instructions exactly:
Then say, verbatim: "Copy this summary AND your share link to this chat, and post both to the Week 12 discussion board — that completes the assignment."
Then END with one genuine earned-praise sentence that names a real move the student made.

Equivalent route (no AI required)

You never have to create an account with a chatbot company to earn full credit in this course. This route assesses the same objectives as the AI dialogue — handling runtime errors with try and except by exception type, explaining which block runs, and checking a claim about an error by running it — against the same driving question and the same rubric below, for the same 10 points. Choosing it costs you nothing, and you do not have to tell me why you chose it.

What you do. Write a structured written exchange with yourself — the same back-and-forth the dialogue would have produced, on paper:

1. Your position (roughly 150 words). Answer Option A or Option B. 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 this week's terms (exception, try statement, except block, exception type, bare except) correctly.
2. The strongest objection (roughly 100 words). Write the best argument against your own position that you can — for example, the case that one bad line should never stop a report people are waiting for, or the case that a program which keeps going without saying so can mislead the people who rely on it. Argue it honestly; a weak objection you knock over earns no credit.
3. Your response to it (roughly 100 words). Say what you still hold, what changed, and which part of the disagreement is about what Python does and which is about judgment.
4. One thing you would still check (one or two sentences). What would you run, such as a short try statement on one bad line of your own, or the same program with and without a bare except, to settle the factual part of your argument?

Effort. Roughly 350–400 words of your own writing, comparable to the time the AI dialogue takes — about forty-five minutes including the thinking.

What you submit. Post those four parts, under those four labels, as your Week 12 discussion post. That post is your entire submission; this route has no share link.

Participation rubric

This discussion is worth 10 points. The same three criteria score both routes.

Built with The Course Maker · samples.thecoursemaker.com