Exception classes and catching policy

You will be able to

• ✓ Catch the error you expect, not MemoryError by accident
• ✓ Give campus refusals their own type so callers can tell them apart
• ✓ Avoid except Exception around a whole program

Too much and too little

except Exception around a whole attendance job swallows bugs you did not mean to catch — including some you wanted to crash so a scheduler turns red. except IndexError is precise but will miss a KeyError on a weather JSON body. A campus type (BadPin) lets callers catch your refusals without catching MemoryError.

Hierarchies exist so CampusError can be the parent of BadPin and MissingFolder. Callers who care only about PIN catch BadPin. Ops who want any campus refusal catch CampusError. Nobody wraps the process in except Exception.

Named returns here; classes on a laptop

This sandbox has no raise. You return "Reject: pin" versus a generic "Error". The policy is the same: do not pretend every failure is the same string. Copy the class sample onto a laptop.

class CampusError(Exception):
    pass

class BadPin(CampusError):
    pass

def parse_pin(text):
    if len(text) != 6:
        raise BadPin("need 6 digits")
    return text

try:
    parse_pin("12")
except BadPin:
    print("fix the PIN")
# except Exception:  # too much — hides MemoryError
# except IndexError:  # too little — misses this BadPin

Words that matter

Exception class

A named failure type callers can catch.

Catch too much

except Exception around a whole program hides bugs.

Catch too little

except IndexError when the real failure is KeyError or BadPin.

Common mistakes

Example program — Two campus refusals

Separate strings now; separate classes on a laptop.

Your turn — Named pin refusal

If pin is "12", print Reject: pin so that text appears.

Self-assessment

Check your understanding before you mark the lesson complete.