Base CS from zero
When a program fails: multiple-choice review
Crux Multiple-choice synthesis across the failure unit: error vs exception, stack unwinding, reading a trace, undefined behaviour, and debugging as reasoning.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at middle altitude — in the skySix questions that cut across the whole unit. Each one is a small judgement call you make in front of a real failure — not a definition to recite, but a distinction to hold steady: condition versus mechanism, loud versus silent, reasoning versus guessing.
Goal
Confirm you can connect the four lessons into one picture: an error is a condition, an exception is the mechanism that unwinds the stack, the stack trace is the snapshot of that unwind, undefined behaviour is the dangerous silent case, and debugging is reasoning over a deterministic machine.
Quiz
Completed
A program tries to open a file that does not exist. Which of these is the error, and which is the exception?
Heads-up They vary independently. The same missing-file condition can be raised as an exception in one program and handled with a plain check in another. A program can raise an exception, catch it, and continue completely normally — nothing is permanently broken.
Heads-up Both live at the runtime/program level. The split is condition versus mechanism, not software versus hardware: the error is the bad situation, the exception is the runtime's stack-unwinding response to it.
Heads-up It is the other way round. The error is the condition (a fact); the exception is the response (a process of unwinding the stack to find a handler).
Quiz
Completed
main calls a, a calls b, b raises an exception. Only main has a handler. How many frames does the runtime pop, and where does normal control flow resume?
Heads-up A crash only happens when unwinding reaches the bottom with no handler anywhere. main has a handler, so unwinding stops there and main's frame is never popped — only b and a are popped.
Heads-up The handler is in main, but the exception was raised in b. The runtime must unwind b and a first to reach the frame that actually has the handler.
Heads-up a sits between b and main and has no handler, so a's frame is also popped. Two frames (b, then a) are popped before unwinding reaches main.
Quiz
Completed
A four-line stack trace reads (top to bottom): divide, getAge, loadUser, main. A new engineer fixes main first. Why is that the wrong instinct?
Heads-up The outermost call is just where the program started. The exception surfaced at the top line, divide. main appears in the trace only because it is on the call chain, not because it is at fault.
Heads-up A trace is read top-down. The top line is the throw site — where the exception was raised — and each line below is the caller of the line above it, down to the entry at the bottom.
Heads-up A trace is not the program's function list. It contains only the frames that were active on the call stack at the throw — the exact chain of calls that led to the exception.
Quiz
Completed
One program reads index 5 of a 3-element array and raises an 'index out of range' exception. Another reads the same out-of-range cell and returns whatever bits are there, with no error. Which is the more dangerous failure, and why?
Heads-up A loud, defined failure is the good case: it stops control flow and points a trace at the line, so you find and fix it fast. The silent failure is the dangerous one precisely because nothing flags it.
Heads-up Reading the wrong cell is the same bug, but the outcomes diverge completely: the defined error is caught and reported; the undefined-behaviour read is silent and propagates a wrong value with no trace.
Heads-up Continuing to run with a garbage value is not safety — it is the danger. The program serves wrong results that look correct, which is worse than stopping loudly.
Quiz
Completed
In JavaScript, reading index 9 of a 3-element array gives undefined (not a crash), and then your code computes undefined + 1. What happens, and why does it resemble undefined behaviour even though each step is defined?
Heads-up No exception is raised. undefined + 1 evaluates to NaN and the program keeps running. The danger is exactly that it does not stop.
Heads-up undefined does not coerce to 0 in addition; undefined + 1 is NaN. That NaN then contaminates every calculation it touches.
Heads-up JavaScript does check bounds — an out-of-range read returns undefined, which is defined behaviour. The undefined-behaviour-style danger comes from using that undefined without noticing, not from the read itself.
Quiz
Completed
A program returns a wrong total. An engineer starts flipping comparisons and re-running until the number looks right. What is the principled objection, grounded in how the machine works?
Heads-up Making the visible symptom vanish is not removing the bug. A guess can mask a defect that resurfaces with different input. Determinism means the cause is fixed and reasoning can find it.
Heads-up Computers do not behave randomly — fetch-decode-execute is deterministic. The same state always gives the same result, which is exactly what makes the bug findable by reasoning instead of luck.
Heads-up A passing test after a blind change does not prove the cause was found; it may only hide one path to the symptom. You want to change a line only after reasoning has pinned the exact diverging step.
Recap
The unit is one chain: an error is the condition, an exception is the mechanism that stops normal flow and unwinds the call stack frame by frame looking for a handler, and the stack trace is that stack frozen at the throw — read top-down, throw site first. Undefined behaviour is the dangerous case where no error is raised at all and a garbage value travels silently. And because the machine is deterministic, the response to any failure is reasoning, not guessing: form a testable hypothesis, narrow the range, read the trace, check state, then fix the step you have proven is wrong.