Raising and catching failures

Computing · Programming · ages 17-18

Name ______________________ Date ____________

How do you catch one specific error around risky lines?
- Delete the risky lines
- Try them, with except naming that error
- Restart the computer
Your program opens a name that does not exist. Which exception arrives?
- FileNotFoundError
- ValueError
- IndexError
A raised exception that nobody catches prints an error and stops the program.
Circle one: True False
One program reads a missing file and parses a bad number. How should it guard both?
- Catch each separately with its own recovery
- One shared silent catcher for all
- Catch nothing and hope
Your function needs a positive number but gets a negative. What should it do?
- Return a quiet wrong answer
- Delete the input silently
- Raise an exception for the caller
Why is one shared catch all usually the wrong repair?
- It runs too slowly
- It hides faults and carries on blindly
- It deletes the file
What should a good except block do?
- Recover with purpose like a message or retry
- Hide the fault and hope
- Crash louder on purpose
A student writes a bare catcher that just passes on. What is the verdict?
- Fine, silence always heals
- Wrong, it runs before try
- Wrong, it hides the fault with no recovery

Answer key

For grown-ups. Fold this page away before handing over the rest.

Try them, with except naming that error · Try marks the risk and except names the fixable error.
FileNotFoundError · A missing path has its own named error.
True · Only a catcher offers a path to recover.
Catch each separately with its own recovery · Each risk needs its named catcher and fitting reply.
Raise an exception for the caller · Raising forces the caller to face the bad input.
It hides faults and carries on blindly · Naming the error you can fix keeps the rest visible.
Recover with purpose like a message or retry · Recovery answers the named failure directly.
Wrong, it hides the fault with no recovery · An except must recover with purpose, not merely pass.