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 tool error classes — Automation Patterns

Day 7 · ~11 min●

Foundations taught try/except Exception as e — catch everything. Today: notice that exceptions have classes, and the class tells you what went wrong.

python

try:
    something()
except Exception as e:
    print(f"failed: {type(e).__name__}")
    # 'KeyError'        — your code looked up a missing dict key
    # 'ConnectionError' — network couldn't reach the API
    # 'RuntimeError'    — Composio raised because the tool said no
    # 'TimeoutError'    — call took too long

Different classes deserve different responses. Network errors retry. Auth errors don't. Bad-arg errors fix the call. Today: just log the class.

And type(e).__name__ is the string name?

Yes — Foundations week 1. type(e) is the class object; .__name__ is the human-readable class name. "KeyError", "ValueError", etc.

Why is the class enough — won't I want the message too?

Class first, message second. Class is one short token ("KeyError"); message can be paragraph-long. Logs you'll grep need stable, short tokens. We'll add structured logging in week 2 (day 13) — log("step", error_class="KeyError", message=str(e)). For now: the class is the high-signal piece.

Trigger three different errors deliberately so you see what they look like.

Specific error classes

Why classes matter

A blanket except Exception as e: print("failed") tells you nothing. The same handler fires for:

a transient network blip (retry — should recover next attempt)
a wrong-credentials auth error (don't retry — escalate to the user)
a bad argument in your code (don't retry — fix the call)
a rate-limit error (retry with longer backoff)

The class — ConnectionError, PermissionError, ValueError, RuntimeError with a 429 in the message — tells you which.

Logging the class

python

try:
    risky_call()
except Exception as e:
    print(f"caught: {type(e).__name__}: {e}")

type(e).__name__ is short and stable. str(e) is the message; useful but variable. Log both.

Common error classes you'll meet

Class	Likely cause	Action
`KeyError`	dict[key] missed; you assumed a field was there	use `.get(key, default)`
`IndexError`	list[i] but list is shorter	guard with `if items:`
`TypeError`	passing wrong type — `len(None)`	check upstream `.get` defaults
`ValueError`	right type, bad value	validate inputs
`ConnectionError`	network unreachable	retry with backoff
`TimeoutError`	call exceeded deadline	retry with longer timeout
`PermissionError`	auth failed	reconnect, don't retry
`RuntimeError` (Composio)	tool said no — message has details	inspect `str(e)`

Catching specific classes

Once you know what classes to expect, catch them by name:

python

try:
    risky_call()
except ConnectionError:
    retry()
except PermissionError:
    abort_and_alert()
except Exception as e:
    print(f"unexpected: {type(e).__name__}: {e}")
    raise

The specific handlers fire first; the catch-all is the fallback. Always have a catch-all Exception handler — surprise classes shouldn't crash silently.

Triggering errors deliberately

For today's lesson, force three different classes to fire:

python

# KeyError
d = {}
try:
    d["missing"]
except Exception as e:
    print(type(e).__name__)

# ZeroDivisionError
try:
    1 / 0
except Exception as e:
    print(type(e).__name__)

# ValueError
try:
    int("not a number")
except Exception as e:
    print(type(e).__name__)

Three errors deliberately raised; three class names printed. The shape generalizes to any try/except.

Day 7 · ~11 min●

Foundations taught try/except Exception as e — catch everything. Today: notice that exceptions have classes, and the class tells you what went wrong.

python

try:
    something()
except Exception as e:
    print(f"failed: {type(e).__name__}")
    # 'KeyError'        — your code looked up a missing dict key
    # 'ConnectionError' — network couldn't reach the API
    # 'RuntimeError'    — Composio raised because the tool said no
    # 'TimeoutError'    — call took too long

Different classes deserve different responses. Network errors retry. Auth errors don't. Bad-arg errors fix the call. Today: just log the class.

And type(e).__name__ is the string name?

Yes — Foundations week 1. type(e) is the class object; .__name__ is the human-readable class name. "KeyError", "ValueError", etc.

Why is the class enough — won't I want the message too?

Trigger three different errors deliberately so you see what they look like.

Specific error classes

Why classes matter

A blanket except Exception as e: print("failed") tells you nothing. The same handler fires for:

a transient network blip (retry — should recover next attempt)
a wrong-credentials auth error (don't retry — escalate to the user)
a bad argument in your code (don't retry — fix the call)
a rate-limit error (retry with longer backoff)

The class — ConnectionError, PermissionError, ValueError, RuntimeError with a 429 in the message — tells you which.

Logging the class

python

try:
    risky_call()
except Exception as e:
    print(f"caught: {type(e).__name__}: {e}")

type(e).__name__ is short and stable. str(e) is the message; useful but variable. Log both.

Common error classes you'll meet

Class	Likely cause	Action
`KeyError`	dict[key] missed; you assumed a field was there	use `.get(key, default)`
`IndexError`	list[i] but list is shorter	guard with `if items:`
`TypeError`	passing wrong type — `len(None)`	check upstream `.get` defaults
`ValueError`	right type, bad value	validate inputs
`ConnectionError`	network unreachable	retry with backoff
`TimeoutError`	call exceeded deadline	retry with longer timeout
`PermissionError`	auth failed	reconnect, don't retry
`RuntimeError` (Composio)	tool said no — message has details	inspect `str(e)`

Catching specific classes

Once you know what classes to expect, catch them by name:

python

try:
    risky_call()
except ConnectionError:
    retry()
except PermissionError:
    abort_and_alert()
except Exception as e:
    print(f"unexpected: {type(e).__name__}: {e}")
    raise

The specific handlers fire first; the catch-all is the fallback. Always have a catch-all Exception handler — surprise classes shouldn't crash silently.

Triggering errors deliberately

For today's lesson, force three different classes to fire:

python

# KeyError
d = {}
try:
    d["missing"]
except Exception as e:
    print(type(e).__name__)

# ZeroDivisionError
try:
    1 / 0
except Exception as e:
    print(type(e).__name__)

# ValueError
try:
    int("not a number")
except Exception as e:
    print(type(e).__name__)

Three errors deliberately raised; three class names printed. The shape generalizes to any try/except.

Specific error classes

Why classes matter

Logging the class

Common error classes you'll meet

Catching specific classes

Triggering errors deliberately

Specific error classes

Why classes matter

Logging the class

Common error classes you'll meet

Catching specific classes

Triggering errors deliberately

Specific error classes

Why classes matter

Logging the class

Common error classes you'll meet

Catching specific classes

Triggering errors deliberately

Sign up to practice

Specific error classes

Why classes matter

Logging the class

Common error classes you'll meet

Catching specific classes

Triggering errors deliberately

Sign up to practice