🛡️ Try/Catch Blocks & Error Handling

Why Error Handling Matters

Imagine you're driving and the engine starts making a strange noise. You'd much rather have a dashboard warning light — something that tells you what's wrong and lets you pull over safely — than have the car simply stop dead in the fast lane. Error handling is that dashboard light for your code: it lets your program notice a problem, respond to it, and keep the rest of the application running.

Without it, a single unexpected value can throw an uncaught exception that halts the current call stack. In the browser that can leave a half-rendered, frozen page; on a Node.js server it can crash the entire process and take every other user's request down with it. Handling errors deliberately is what turns "it works on my machine" into "it works in production."

The Error Object & Its Types

When something goes wrong, JavaScript creates an Error object. Every error carries three especially useful properties:

• name — the category, e.g. "TypeError"
• message — a human-readable description of what happened
• stack — the call stack at the moment the error was created (invaluable for debugging)

The language ships with a family of specialized error types, all descending from the base Error:

You can create one yourself and inspect it:

const err = new TypeError("Expected a number");
console.log(err.name);    // "TypeError"
console.log(err.message); // "Expected a number"
console.log(err.stack);   // "TypeError: Expected a number\n    at ..."

// Every specific type is an Error:
console.log(err instanceof TypeError); // true
console.log(err instanceof Error);     // true

The try/catch Statement

The try/catch statement lets you "try" a block of code and "catch" any error it throws, instead of letting that error crash the program. The catch block receives the error object so you can respond intelligently.

try {
    // Code that might throw
    riskyOperation();
} catch (error) {
    // Runs ONLY if something in try threw
    console.error("An error occurred:", error.message);
}
// Execution continues here either way

How it flows

The key insight: the moment a line inside try throws, JavaScript abandons the rest of the try block and jumps to catch. Lines after the failing one never run.

Example 1: catching a ReferenceError

function greetUser(name) {
    try {
        console.log(message); // 'message' was never declared → ReferenceError
        return `Hello, ${name}!`;
    } catch (error) {
        console.error("Caught:", error.name);      // "ReferenceError"
        console.error("Details:", error.message);  // "message is not defined"
        return `Hello, ${name}! (recovered)`;      // graceful fallback
    }
}

console.log(greetUser("Alice"));
// Caught: ReferenceError
// Details: message is not defined
// Hello, Alice! (recovered)

Example 2: catching a TypeError with a safe default

function calculateTotal(items) {
    try {
        // Fails if items isn't an array of { price } objects
        return items.reduce((sum, item) => sum + item.price, 0);
    } catch (error) {
        console.error("Could not total items:", error.message);
        return 0; // a sensible fallback the caller can rely on
    }
}

console.log(calculateTotal([{ price: 10 }, { price: 20 }])); // 30
console.log(calculateTotal(null));          // 0  (no crash)
console.log(calculateTotal("not an array")); // 0  (no crash)

The finally Block

Sometimes code must run whether or not an error occurred — closing a file, hiding a loading spinner, releasing a database connection. That's what finally is for. It runs after try (and after catch, if one fired), on every path out of the block, even a return.

function processFile(filename) {
    let file;
    try {
        file = openFile(filename);
        const data = readFile(file);   // might throw
        return process(data);          // success path
    } catch (error) {
        console.error("Error processing file:", error.message);
        return "Failed";               // failure path
    } finally {
        // Runs on BOTH paths above — perfect for cleanup
        if (file) {
            closeFile(file);
            console.log("File closed");
        }
    }
}

Throwing & Custom Errors

You don't have to wait for JavaScript to throw — you can raise your own error the instant you detect an invalid state with the throw keyword. Always throw an Error object (not a bare string) so callers get a name, message, and stack.

function divide(a, b) {
    if (b === 0) {
        // ❌ throw "cannot divide by zero";  // loses the stack trace
        throw new Error(`Cannot divide ${a} by zero`); // ✅
    }
    return a / b;
}

Custom error classes

For real applications, define your own Error subclasses. They read like documentation and let callers branch on the kind of failure with instanceof.

class ValidationError extends Error {
    constructor(message) {
        super(message);
        this.name = "ValidationError"; // so error.name is meaningful
    }
}

class AuthError extends Error {
    constructor(message) {
        super(message);
        this.name = "AuthError";
    }
}

function validateUser(user) {
    if (!user)              throw new ValidationError("User object is required");
    if (!user.email)        throw new ValidationError("Email is required");
    if (!user.email.includes("@")) throw new ValidationError("Invalid email format");
    return true;
}

try {
    validateUser({ email: "invalid-email" });
} catch (error) {
    if (error instanceof ValidationError) {
        console.log("Please fix your input:", error.message);
    } else {
        throw error; // not ours — let it bubble up
    }
}
// Please fix your input: Invalid email format

Errors in Asynchronous Code

Here's a trap that catches every beginner: a plain try/catch cannot catch an error that happens later, inside a callback or an un-awaited promise. The try block finishes long before the async work fails. There are two correct ways to handle async errors.

1. try/catch with async/await

Because await pauses the function until the promise settles, a rejected promise throws right at the await line — so an ordinary try/catch around it works perfectly.

async function fetchUserData(userId) {
    try {
        const response = await fetch(`/api/users/${userId}`);

        // fetch only rejects on network failure — a 404/500 is still "ok: false"
        if (!response.ok) {
            throw new Error(`HTTP error! status: ${response.status}`);
        }

        const user = await response.json();
        if (!user.email) throw new ValidationError("User data missing email");
        return user;
    } catch (error) {
        if (error instanceof ValidationError) {
            console.error("Bad data:", error.message);
            return null;
        }
        if (error instanceof TypeError) {
            console.error("Network problem:", error.message);
            return null;
        }
        throw error; // unknown — re-throw
    }
}

2. .catch() on a promise chain

If you're using .then() instead of await, attach a .catch() at the end. One .catch() handles a rejection from any step above it in the chain.

function fetchData(url) {
    return fetch(url)
        .then(response => {
            if (!response.ok) throw new Error(`HTTP ${response.status}`);
            return response.json();
        })
        .then(data => {
            if (!data.isValid) throw new ValidationError("Invalid data received");
            return data;
        })
        .catch(error => {
            // Catches a throw from EITHER .then above
            console.error("Request failed:", error.message);
            return { error: error.message }; // recover with a fallback value
        });
}

Global Error Handlers

Even careful code misses something. A top-level safety net lets you log unexpected failures (to a monitoring service like Sentry) and show the user a friendly message instead of a broken page.

// Browser: catch synchronous errors that escaped every try/catch
window.addEventListener("error", (event) => {
    console.error("Uncaught error:", event.message, "at", event.filename);
    reportToService(event.error);
});

// Browser: catch promises that rejected with no .catch()
window.addEventListener("unhandledrejection", (event) => {
    console.error("Unhandled rejection:", event.reason);
    reportToService(event.reason);
    event.preventDefault(); // stop the default console spam
});

On the server, Node.js exposes the equivalent hooks. Note that after an uncaughtException the process is in an unknown state — log it and exit, don't try to keep running.

// Node.js
process.on("unhandledRejection", (reason) => {
    console.error("Unhandled rejection:", reason);
});
process.on("uncaughtException", (error) => {
    console.error("Uncaught exception:", error);
    process.exit(1); // restart cleanly via a process manager
});

Practice & Quiz

function safeJSONParse(text, fallback = null) {
    // TODO: try to parse; on failure log a warning and return fallback
}

console.log(safeJSONParse('{"name":"John"}')); // { name: "John" }
console.log(safeJSONParse("not json"));         // null
console.log(safeJSONParse("nope", {}));         // {}

function safeJSONParse(text, fallback = null) {
    try {
        return JSON.parse(text);
    } catch (error) {
        console.warn("Invalid JSON, using fallback:", error.message);
        return fallback;
    }
}

const delay = (ms) => new Promise(resolve => setTimeout(resolve, ms));

async function retry(operation, maxAttempts = 3) {
    let lastError;
    for (let attempt = 1; attempt <= maxAttempts; attempt++) {
        try {
            return await operation();       // success — done
        } catch (error) {
            lastError = error;
            console.warn(`Attempt ${attempt} failed: ${error.message}`);
            if (attempt < maxAttempts) {
                await delay(200 * attempt);  // exponential-ish backoff
            }
        }
    }
    throw lastError; // all attempts exhausted
}

Best Practices & Pitfalls

✅ Do

• Catch the specific errors you can recover from; re-throw the rest
• Always log or handle a caught error — never leave the catch block empty
• Throw Error objects (or subclasses), never bare strings
• Write descriptive messages: `Cannot divide ${a} by zero`, not "Error"
• Use finally for cleanup that must run on every path
• Check response.ok after every fetch

❌ Don't

• Swallow errors silently — catch (e) {} hides real bugs
• Wrap a giant block in one try so you can't tell which line failed
• Use exceptions for ordinary control flow (return null for "not found" instead)
• Expect a synchronous try/catch to catch a callback's error
• return from a finally block — it overrides your real result

// 🚫 Looks harmless, hides everything
try { riskyOperation(); } catch (e) {}

// ✅ At minimum, log it
try {
    riskyOperation();
} catch (error) {
    console.error("riskyOperation failed:", error);
    throw error; // or handle it — but never ignore it
}

Summary

📚 Additional Resources

• MDN — try...catch
• MDN — Error
• MDN — Control flow and error handling

🚀 What's Next?

You can now handle errors gracefully — but how do you find the bugs that cause them in the first place? Next up: Debugging with Chrome DevTools, where you'll set breakpoints, inspect the call stack, and watch your code run one line at a time.