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.

Wrap an API Call in Try/Except With a Safe Default — Automation For Makers

Day 13 · ~12 min●

APIs fail. Network drops. Tokens expire. If one execute_action call raises an exception, your function crashes and the rest of your pipeline never runs. What's the minimum wrapper that turns a crash into a safe default?

A try/except? Like, wrap the call, catch any exception, and return zero instead of crashing?

Exactly. The try block holds the API call plus the extraction. The except block returns a safe default. The caller always gets an integer back — the function never raises:

python

try:
    result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
    return len(result.get("messages", []))
except Exception:
    return 0

Is except Exception too broad? Shouldn't I catch a specific error?

For a boundary wrapper — where every error means 'we couldn't get the count' — Exception is correct. You would narrow it only if different exception types need different defaults. Here's the full function with a diagnostic print:

python

def safe_fetch_with_default(max_results: int, default: int) -> int:
    try:
        result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
        count = len(result.get("messages", []))
        print(f"Safely fetched {count} emails (default would have been {default})")
        return count
    except Exception as exc:
        print(f"Gmail call failed ({exc}); falling back to default {default}")
        return default

Does the print statement in the except block help in production, or is it noise?

In production you'd swap the print for a real logger, but the principle is identical: never swallow a failure silently. You need to know something fell back to the default, or a flaky API becomes a silent bug.

So now every function I write can keep running even if one API dies — the pipeline's resilience starts here?

That is why try/except lives in Week 2 on this track. Every Week 3 and Week 4 lesson assumes you can wrap a call and keep going. This is the pattern.

Try/Except with Safe Default

TL;DR: Wrap the API call in a try block, return a default in the except block. The function never raises, the caller always gets a number.

try — API call plus extraction live together
except Exception — broad catch at the boundary is correct here
Log the fallback — never swallow a failure silently

Narrow vs broad catch

Scope	Use when
`except Exception`	boundary wrapper — any error means 'use default'
`except SpecificError`	you have different responses per error type

Day 13 · ~12 min●

A try/except? Like, wrap the call, catch any exception, and return zero instead of crashing?

Exactly. The try block holds the API call plus the extraction. The except block returns a safe default. The caller always gets an integer back — the function never raises:

python

try:
    result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
    return len(result.get("messages", []))
except Exception:
    return 0

Is except Exception too broad? Shouldn't I catch a specific error?

python

def safe_fetch_with_default(max_results: int, default: int) -> int:
    try:
        result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results})
        count = len(result.get("messages", []))
        print(f"Safely fetched {count} emails (default would have been {default})")
        return count
    except Exception as exc:
        print(f"Gmail call failed ({exc}); falling back to default {default}")
        return default

Does the print statement in the except block help in production, or is it noise?

So now every function I write can keep running even if one API dies — the pipeline's resilience starts here?

That is why try/except lives in Week 2 on this track. Every Week 3 and Week 4 lesson assumes you can wrap a call and keep going. This is the pattern.

Try/Except with Safe Default

TL;DR: Wrap the API call in a try block, return a default in the except block. The function never raises, the caller always gets a number.

try — API call plus extraction live together
except Exception — broad catch at the boundary is correct here
Log the fallback — never swallow a failure silently

Narrow vs broad catch

Scope	Use when
`except Exception`	boundary wrapper — any error means 'use default'
`except SpecificError`	you have different responses per error type

def safe_fetch_with_default(max_results: int, default: int) -> int: try: result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": max_results}) count = len(result.get("messages", [])) print(f"Safely fetched {count} emails (default would have been {default})") return count except Exception as exc: print(f"Gmail call failed ({exc}); falling back to default {default}") return default

Try/Except with Safe Default

TL;DR: Wrap the API call in a try block, return a default in the except block. The function never raises, the caller always gets a number.

try — API call plus extraction live together

except Exception — broad catch at the boundary is correct here

Log the fallback — never swallow a failure silently

Narrow vs broad catch

Scope	Use when
`except Exception`	boundary wrapper — any error means 'use default'
`except SpecificError`	you have different responses per error type

Try/Except with Safe Default

TL;DR: Wrap the API call in a try block, return a default in the except block. The function never raises, the caller always gets a number.

try — API call plus extraction live together

except Exception — broad catch at the boundary is correct here

Log the fallback — never swallow a failure silently

Narrow vs broad catch

Scope	Use when
`except Exception`	boundary wrapper — any error means 'use default'
`except SpecificError`	you have different responses per error type

Try/Except with Safe Default

Narrow vs broad catch

Try/Except with Safe Default

Narrow vs broad catch

Try/Except with Safe Default

Narrow vs broad catch

Sign up to practice

Try/Except with Safe Default

Narrow vs broad catch

Sign up to practice