\n<\/p>\n
You’re not handling errors. You’re hiding them.<\/p>\n
Every app crashes. Every API fails. Every database hiccups at 2am on a Friday.The difference between a good dev and a great one? What happens next.<\/p>\n
Let’s roast your error handling \u2014 then make it legendary.<\/p>\n
\ud83e\udd26 Level 0: The “Trust Me Bro” Dev<\/p>\n
No try\/catch at all. Just vibes.<\/p>\n
const data = await fetchUserData(userId);
\nconsole.log(data.profile.name); \/\/ \ud83d\udca5 TypeError: Cannot read properties of undefined<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
The crime: One bad response nukes the entire app. Users see a white screen. You get a 3am Slack ping.<\/p>\n
\ud83d\udc23 Level 1: The Junior \u2014 “I Googled try\/catch”<\/p>\n
try {
\n const data = await fetchUserData(userId);
\n setUser(data);
\n} catch (err) {
\n console.log(err); \/\/ \ud83d\udc48 and… that’s it. shipped.
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
What’s wrong here?<\/p>\n
console.log in production helps nobody \u2014 users still see a broken UI
\nNo distinction between a 404 and a 500 \u2014 every error is treated the same
\nThe error disappears into the void (or a DevTools tab nobody has open)<\/p>\n
err might be null, a string, or an Error object \u2014 you’re not checking<\/p>\n
The mindset: “At least it won’t crash.” \u2014 Yeah, it just silently breaks instead. Cool.<\/p>\n
\ud83d\udcc8 Level 2: The Mid-Level \u2014 “I’ve Been Burned Before”<\/p>\n
Now we’re thinking. You’ve seen production fires. You have trust issues with APIs. Good.<\/p>\n
2a \u2014 Typed errors, real messages<\/p>\n
try {
\n const data = await fetchUserData(userId);
\n setUser(data);
\n} catch (err) {
\n if (err instanceof NetworkError) {
\n showToast(“Connection lost. Check your internet.”, “warning”);
\n } else if (err.status === 404) {
\n showToast(“User not found.”, “error”);
\n } else {
\n showToast(“Something went wrong. We’re on it.”, “error”);
\n logger.error(“(fetchUserData)”, { userId, err }); \/\/ \ud83d\udc48 goes to Sentry\/Datadog
\n }
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
\u2705 Users get useful feedback, not a frozen screen\u2705 Engineers get structured logs, not a haystack of console.logs<\/p>\n
2b \u2014 Undo previous operations (the “atomic mindset”)<\/p>\n
Imagine you’re updating a user’s profile and their avatar. Step 1 succeeds. Step 2 fails.Congrats \u2014 your user now has a corrupted half-state.<\/p>\n
let previousProfile = null;<\/p>\n
try {
\n previousProfile = await getProfile(userId); \/\/ snapshot
\n await updateProfile(userId, newProfileData); \/\/ step 1
\n await uploadAvatar(userId, newAvatar); \/\/ step 2 \ud83d\udca5 fails here
\n} catch (err) {
\n logger.error(“Profile update failed”, { err });<\/p>\n
\/\/ \u21a9\ufe0f Roll back step 1 since step 2 failed
\n if (previousProfile) {
\n await updateProfile(userId, previousProfile);
\n }<\/p>\n
showToast(“Update failed. Your profile has been restored.”, “warning”);
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
\u2705 Users never see broken half-state\u2705 Rollback is explicit, not accidental<\/p>\n
2c \u2014 Wrap it in a clean utility (stop repeating yourself)<\/p>\n
Tired of writing try\/catch 50 times? Make a helper:<\/p>\n
\/\/ utils\/tryCatch.js
\nexport async function tryCatch(fn, fallback = null) {
\n try {
\n const result = await fn();
\n return (result, null);
\n } catch (err) {
\n return (fallback, err);
\n }
\n}<\/p>\n
\/\/ Usage \u2014 clean, flat, readable
\nconst (user, err) = await tryCatch(() => fetchUserData(userId));<\/p>\n
if (err) {
\n showToast(“Couldn’t load user.”, “error”);
\n return;
\n}<\/p>\n
setUser(user);<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
\u2705 No more deeply nested try\/catch pyramids\u2705 Forces you to handle the error at call site \u2014 can’t ignore it<\/p>\n
\ud83e\udde0 Level 3: The Senior \u2014 “I’ve Seen Things”<\/p>\n
You don’t just catch errors. You anticipate them. You build systems that heal themselves.<\/p>\n
3a \u2014 Retry queue with exponential backoff<\/p>\n
Networks are flaky. Don’t give up on the first failure.<\/p>\n
async function fetchWithRetry(fn, { retries = 3, delay = 500 } = {}) {
\n for (let attempt = 1; attempt retries; attempt++) {
\n try {
\n return await fn();
\n } catch (err) {
\n const isLast = attempt === retries;
\n const isRetryable = err.status >= 500 || err instanceof NetworkError;<\/p>\n
if (isLast || !isRetryable) throw err; \/\/ don’t retry 401s or 404s<\/p>\n
const backoff = delay * 2 ** (attempt – 1); \/\/ 500ms \u2192 1s \u2192 2s
\n logger.warn(`Attempt ${attempt} failed. Retrying in ${backoff}ms…`);
\n await sleep(backoff);
\n }
\n }
\n}<\/p>\n
\/\/ Usage
\nconst data = await fetchWithRetry(() => fetchUserData(userId));<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
\u2705 Temporary blips are invisible to users\u2705 Smart: retries server errors, not client errors (no point retrying a 401)<\/p>\n
3b \u2014 Circuit breaker (stop hammering a dead service)<\/p>\n
A retry queue is great \u2014 unless the whole service is down. Then you’re just DDoS-ing a corpse.<\/p>\n
class CircuitBreaker {
\n constructor(threshold = 5, timeout = 30_000) {
\n this.failures = 0;
\n this.threshold = threshold;
\n this.timeout = timeout;
\n this.state = “CLOSED”; \/\/ CLOSED = healthy, OPEN = tripped, HALF_OPEN = testing
\n this.nextAttempt = Date.now();
\n }<\/p>\n
async call(fn) {
\n if (this.state === “OPEN”) {
\n if (Date.now() this.nextAttempt) {
\n throw new Error(“Circuit open \u2014 service unavailable”);
\n }
\n this.state = “HALF_OPEN”;
\n }<\/p>\n
try {
\n const result = await fn();
\n this.reset();
\n return result;
\n } catch (err) {
\n this.recordFailure();
\n throw err;
\n }
\n }<\/p>\n
recordFailure() {
\n this.failures++;
\n if (this.failures >= this.threshold) {
\n this.state = “OPEN”;
\n this.nextAttempt = Date.now() + this.timeout;
\n logger.error(“\ud83d\udd34 Circuit breaker TRIPPED”);
\n }
\n }<\/p>\n
reset() {
\n this.failures = 0;
\n this.state = “CLOSED”;
\n }
\n}<\/p>\n
\/\/ Usage
\nconst userServiceBreaker = new CircuitBreaker();
\nconst data = await userServiceBreaker.call(() => fetchUserData(userId));<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
\u2705 Failing fast is kind \u2014 users get an error immediately, not after 10s of retrying\u2705 Gives the downstream service a breather to recover<\/p>\n
3c \u2014 Structured error classes (errors that mean something)<\/p>\n
Stop throwing raw strings or generic Errors. Give your errors context.<\/p>\n
class AppError extends Error {
\n constructor(message, { code, statusCode = 500, context = {}, retryable = false } = {}) {
\n super(message);
\n this.name = “AppError”;
\n this.code = code;
\n this.statusCode = statusCode;
\n this.context = context;
\n this.retryable = retryable;
\n this.timestamp = new Date().toISOString();
\n }
\n}<\/p>\n
\/\/ Subclass for specificity
\nclass AuthError extends AppError {
\n constructor(message, context) {
\n super(message, { code: “AUTH_ERROR”, statusCode: 401, context, retryable: false });
\n }
\n}<\/p>\n
class ServiceUnavailableError extends AppError {
\n constructor(service, context) {
\n super(`${service} is unavailable`, { code: “SERVICE_DOWN”, statusCode: 503, context, retryable: true });
\n }
\n}<\/p>\n
\/\/ Throwing
\nthrow new ServiceUnavailableError(“UserService”, { userId, attempt: 3 });<\/p>\n
\/\/ Catching
\ncatch (err) {
\n if (err instanceof AuthError) {
\n redirectToLogin();
\n } else if (err instanceof AppError && err.retryable) {
\n retryQueue.add(err);
\n } else {
\n logger.error(err.code, err.context);
\n showToast(“Unexpected error. Engineers notified.”);
\n }
\n}<\/p>\n
Enter fullscreen mode<\/p>\n
Exit fullscreen mode<\/p>\n
\u2705 Catch blocks can make decisions, not just log and pray\u2705 Every error carries its own context \u2014 no more guessing what happened<\/p>\n
\ud83d\uddfa\ufe0f The Full Picture<\/p>\n
What you do
\nJunior
\nMid
\nSenior<\/p>\n
Catch errors
\n\u2705
\n\u2705
\n\u2705<\/p>\n
Inform the user
\n\u274c
\n\u2705
\n\u2705<\/p>\n
Send to a logger
\n\u274c
\n\u2705
\n\u2705<\/p>\n
Typed\/structured errors
\n\u274c
\n\u26a0\ufe0f partial
\n\u2705<\/p>\n
Rollback on failure
\n\u274c
\n\u2705
\n\u2705<\/p>\n
Retry transient errors
\n\u274c
\n\u274c
\n\u2705<\/p>\n
Circuit breaker
\n\u274c
\n\u274c
\n\u2705<\/p>\n
Errors are self-describing
\n\u274c
\n\u274c
\n\u2705<\/p>\n
\u2705 The Golden Rules<\/p>\n
Never swallow errors silently. A hidden bug is a time bomb.<\/p>\n
Always tell the user something. Frozen UI is worse than an error message.<\/p>\n
Log with context, not just a message \u2014 what failed, who triggered it, when.<\/p>\n
Not all errors are equal \u2014 404 \u2260 500 \u2260 NetworkError. Handle them differently.<\/p>\n
Retryable \u2260 always retry \u2014 client errors (4xx) should fail fast.<\/p>\n
Leave the system in a valid state. Roll back or compensate when operations are partial.<\/p>\n
Your catch block is business logic \u2014 treat it that way.<\/p>\n
“The mark of a great engineer isn’t writing code that never fails.It’s writing code that fails gracefully.”<\/p>\n
Now go fix your try\/catches. \ud83d\udee0\ufe0f<\/p>\n