How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Specific exceptions — Python Patterns

Day 6 · ~12 min●

Each kind of failure has its own exception type. Catching the right one tells the reader exactly what you expected to fail.

python

int("hello")    # ValueError: invalid literal for int() with base 10: 'hello'
d["missing"]    # KeyError: 'missing'
open("nope")    # FileNotFoundError: [Errno 2] No such file or directory: 'nope'

Each one a different name, each one descriptive.

And often you want to handle them differently. "Bad input" might mean prompt the user again; "file not found" might mean fall back to defaults. Same try block, two except clauses:

python

try:
    text = open(path).read()
    n = int(text)
except FileNotFoundError:
    n = 0                            # default
except ValueError:
    print("file content isn't a number")
    n = 0

Or one except with a tuple of types?

Yes — if the handling is the same:

python

except (FileNotFoundError, ValueError):
    n = 0

Use separate except blocks when the response is different. Use the tuple form when the response is the same.

And today we convert a list of strings to ints, skipping the ones that fail.

Right. int("42") works, int("oops") raises ValueError. Catch the ValueError, print "skip", continue with the rest.

The exception types you'll meet most

Exception	When it fires
`KeyError`	`d["missing"]` on a dict
`IndexError`	`lst[100]` past the end of a list
`ValueError`	`int("hello")`, `float("abc")` — wrong shape input to a parser
`TypeError`	`"a" + 1` — wrong types combined
`FileNotFoundError`	`open("missing.txt")`
`ZeroDivisionError`	`n / 0`
`AttributeError`	`value.method_that_doesnt_exist()`

All inherit from a base Exception class, but you'll almost always catch a specific one.

Multiple `except` blocks

Different handling per type:

python

try:
    do_work()
except FileNotFoundError:
    print("file missing")
except PermissionError:
    print("can't read it")
except ValueError:
    print("bad content")

Python tries each except in order; first match wins.

One `except`, tuple of types

Same handling for several types:

python

try:
    do_work()
except (FileNotFoundError, PermissionError):
    print("can't access")

`except` order matters with inheritance

If you catch a parent class before a child, the child is unreachable:

python

try:
    open("x").read()
except Exception:           # catches FileNotFoundError too
    handle_generally()
except FileNotFoundError:   # never runs — Exception caught it first
    handle_specifically()

List the most specific first.

Pattern — skip and continue inside a loop

A classic shape: you have a list of inputs, some are bad, you want to process the good ones and report the bad ones.

python

for s in ["10", "oops", "20"]:
    try:
        n = int(s)
        print(n)
    except ValueError:
        print("skip")
# 10
# skip
# 20

The try is inside the loop body so each iteration starts fresh — one bad item doesn't kill the loop.

Day 6 · ~12 min●

Each kind of failure has its own exception type. Catching the right one tells the reader exactly what you expected to fail.

python

int("hello")    # ValueError: invalid literal for int() with base 10: 'hello'
d["missing"]    # KeyError: 'missing'
open("nope")    # FileNotFoundError: [Errno 2] No such file or directory: 'nope'

Each one a different name, each one descriptive.

And often you want to handle them differently. "Bad input" might mean prompt the user again; "file not found" might mean fall back to defaults. Same try block, two except clauses:

python

try:
    text = open(path).read()
    n = int(text)
except FileNotFoundError:
    n = 0                            # default
except ValueError:
    print("file content isn't a number")
    n = 0

Or one except with a tuple of types?

Yes — if the handling is the same:

python

except (FileNotFoundError, ValueError):
    n = 0

Use separate except blocks when the response is different. Use the tuple form when the response is the same.

And today we convert a list of strings to ints, skipping the ones that fail.

Right. int("42") works, int("oops") raises ValueError. Catch the ValueError, print "skip", continue with the rest.

The exception types you'll meet most

Exception	When it fires
`KeyError`	`d["missing"]` on a dict
`IndexError`	`lst[100]` past the end of a list
`ValueError`	`int("hello")`, `float("abc")` — wrong shape input to a parser
`TypeError`	`"a" + 1` — wrong types combined
`FileNotFoundError`	`open("missing.txt")`
`ZeroDivisionError`	`n / 0`
`AttributeError`	`value.method_that_doesnt_exist()`

All inherit from a base Exception class, but you'll almost always catch a specific one.

Multiple `except` blocks

Different handling per type:

python

try:
    do_work()
except FileNotFoundError:
    print("file missing")
except PermissionError:
    print("can't read it")
except ValueError:
    print("bad content")

Python tries each except in order; first match wins.

One `except`, tuple of types

Same handling for several types:

python

try:
    do_work()
except (FileNotFoundError, PermissionError):
    print("can't access")

`except` order matters with inheritance

If you catch a parent class before a child, the child is unreachable:

python

try:
    open("x").read()
except Exception:           # catches FileNotFoundError too
    handle_generally()
except FileNotFoundError:   # never runs — Exception caught it first
    handle_specifically()

List the most specific first.

Pattern — skip and continue inside a loop

A classic shape: you have a list of inputs, some are bad, you want to process the good ones and report the bad ones.

python

for s in ["10", "oops", "20"]:
    try:
        n = int(s)
        print(n)
    except ValueError:
        print("skip")
# 10
# skip
# 20

The try is inside the loop body so each iteration starts fresh — one bad item doesn't kill the loop.

The exception types you'll meet most

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Pattern — skip and continue inside a loop

The exception types you'll meet most

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Pattern — skip and continue inside a loop

The exception types you'll meet most

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Pattern — skip and continue inside a loop

Sign up to practice

The exception types you'll meet most

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Pattern — skip and continue inside a loop

Sign up to practice

The exception types you'll meet most

Multiple except blocks

One except, tuple of types

except order matters with inheritance

Pattern — skip and continue inside a loop

The exception types you'll meet most

Multiple except blocks

One except, tuple of types

except order matters with inheritance

Pattern — skip and continue inside a loop

The exception types you'll meet most

Multiple except blocks

One except, tuple of types

except order matters with inheritance

Pattern — skip and continue inside a loop

Sign up to practice

The exception types you'll meet most

Multiple except blocks

One except, tuple of types

except order matters with inheritance

Pattern — skip and continue inside a loop

Sign up to practice

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance

Multiple `except` blocks

One `except`, tuple of types

`except` order matters with inheritance