From scattered try/catch blocks to a clean, production-ready global error strategy.

If you have been writing Node.js and Express applications for a while, you have probably written a controller that looks like this:

// ❌ The "Old Way" - Painful and Repetitive

exports.getUser = async (req, res, next) => {

try {

const user = await User.findById(req.params.id);

if(!user) {

return res.status(404).json({ status: 'fail', message: 'User not found' });

}

res.status(200).json({ status: 'success', data: { user } });

} catch (err) {

res.status(500).json({ status: 'error', message: 'Something went wrong' });

}

};

At first glance, this looks reasonable. But as your codebase grows, problems quickly emerge.

Why This Approach Fails at Scale

What works for one controller becomes a maintenance nightmare for fifty.

1. Massive Duplication

Every async controller repeats the same try/catch logic.

2. Inconsistent Error Responses

Some endpoints return fail, others error. Messages differ. Status codes drift.

3. No Separation of Concerns

Controllers now:

Fetch data
Format responses
Decide error messages
Handle unexpected failures

4. Security Risks

In production, you must not expose stack traces or internal error details.

5. No Distinction Between Error Types

Invalid MongoDB IDs
Duplicate fields
JWT expiration
Programmer bugs

All treated as “Something went wrong”.

The Correct Mental Model for Express Errors

Before writing better code, we need a better conceptual model.

Not all errors are equal.

Two Types of Errors

Operational errors (expected)
Invalid input
Resource not found
Duplicate email
Expired JWT
Programming errors (bugs)
Undefined variables
Broken logic
Library misuse

Your API should:

Handle operational errors gracefully
Hide programming errors from users

This distinction is the foundation of professional Express error handling.

Step 1: Centralize Async Error Handling

The Problem

Express does not automatically catch rejected promises.

The Solution: `catchAsync`

const catchAsync = (fn) => {

return (req, res, next) => {

fn(req, res, next).catch((err) => next(err));

};

};

module.exports = catchAsync;

This small utility eliminates try/catch from every controller.

Usage

const getUser = catchAsync(async (req, res, next) => {

const user = await User.findById(req.params.id);

if (!user) {

return next(new AppError("No user found with that ID", 404));

}

res.status(200).json({

status: "success",

data: { user },

});

});

Clean. Focused. No duplication.

Step 2: Create a Custom Error Class

JavaScript’s native Error object lacks context, like HTTP status codes.

Introducing `AppError`

class AppError extends Error {

constructor(message, statusCode) {

super(message);

this.statusCode = statusCode;

this.status = `${statusCode}`.startsWith("4") ? "fail" : "error";

this.isOperational = true;

Error.captureStackTrace(this, this.constructor);

}

}

module.exports = AppError;

Why This Matters

Consistent error shape
Explicit HTTP status codes
Ability to distinguish trusted vs untrusted errors

This pattern is inspired by production Node.js practices discussed in the Node.js Error Handling Guide.

Step 3: Handle Mongoose Errors Properly

Mongoose throws structured errors. Ignoring them wastes valuable context.

Common Mongoose Errors

Invalid ObjectId (CastError)

const handleCastErrorDB = (err) =>

new AppError(`Invalid ${err.path}: ${err.value}.`, 400);

Duplicate Fields (11000)

const handleDuplicateFieldsDB = (err) => {

const value = Object.values(err.keyValue)[0];

return new AppError(

`"${value}" already exists. Please use another value!`,

400

);

};

Validation Errors

const handleValidationErrorDB = (err) => {

const errors = Object.values(err.errors).map((el) => el.message);

return new AppError(`Invalid input data. ${errors.join(". ")}`, 400);

};

Now, database errors are presented as user-friendly messages, not cryptic dumps.

Step 4: Handle JWT Errors Explicitly

Authentication errors deserve clear, intentional responses.

const handleJWTError = () =>

new AppError("Invalid token. Please log in again!", 401);

const handleJWTExpiredError = () =>

new AppError("Your token has expired! Please log in again.", 401);

No more guessing why authentication failed.

Step 5: The Global Error Handler (The Brain)

Now for the heavy lifter. Instead of handling errors in every controller, we build one middleware to rule them all.

This middleware sits at the end of your app.js. Every error from anywhere in your app eventually bubbles down to this function.

Here is the strategy:

Dev Mode: Send everything. Stack traces, full error objects. We want to debug.
Prod Mode: Sanitize. Only send nice messages for isOperational errors. Hide the rest.
Mongoose Translation: Mongoose errors (like "Duplicate Key") are ugly. We need to translate them into human-readable AppErrors.

The Code Breakdown

Here is the implementation of our controllers/errorController.js:

const AppError = require("../utils/appError");

// 1. HELPER FUNCTIONS TO TRANSLATE DB ERRORS

// ---------------------------------------------------

const handleCastErrorDB = (err) =>

new AppError(`Invalid ${err.path}: ${err.value}.`, 400);

const handleDuplicateFieldsDB = (err) => {

// Regex to find the value inside quotes (e.g., "email@test.com")

const value = err.keyValue

? Object.values(err.keyValue)[0]

: "duplicate value";

return new AppError(

`"${value}" already exists. Please use another value!`,

400

);

};

const handleValidationErrorDB = (err) => {

// Loop over all validation errors and join them

const errors = Object.values(err.errors).map((el) => el.message);

return new AppError(`Invalid input data. ${errors.join(". ")}`, 400);

};

const handleJWTError = () =>

new AppError("Invalid token. Please log in again!", 401);

const handleJWTExpiredError = () =>

new AppError("Your token has expired! Please log in again.", 401);

// 2. RESPONSE SENDERS

// ---------------------------------------------------

const sendErrorDev = (err, res) => {

res.status(err.statusCode || 500).json({

status: err.status || "error",

error: err,

message: err.message,

stack: err.stack, // Leak stack trace only in Dev!

});

};

const sendErrorProd = (err, res) => {

// A) Operational, trusted error: send message to client

if (err.isOperational) {

res.status(err.statusCode).json({

status: err.status,

message: err.message,

});

}

// B) Programming or other unknown error: don't leak details to client

else {

console.error("ERROR 💥", err); // Log it for the developer

res.status(500).json({

status: "error",

message: "Something went wrong!",

});

}

};

// 3. THE GLOBAL HANDLER

// ---------------------------------------------------

const globalErrorHandler = (err, req, res, next) => {

err.statusCode = err.statusCode || 500;

err.status = err.status || "error";

if (process.env.NODE_ENV === "development") {

sendErrorDev(err, res);

} else if (process.env.NODE_ENV === "production") {

// Shallow copy the error object to modify it safely

let error = { ...err, message: err.message };

// --- ERROR IDENTIFICATION ---

// Here we identify specific Mongoose/JWT errors and transform

// them into nice AppErrors using our helpers.

if (error.name === "CastError") error = handleCastErrorDB(error);

if (error.code === 11000) error = handleDuplicateFieldsDB(error);

if (error.name === "ValidationError") error = handleValidationErrorDB(error);

if (error.name === "JsonWebTokenError") error = handleJWTError();

if (error.name === "TokenExpiredError") error = handleJWTExpiredError();

sendErrorProd(error, res);

}

};

module.exports = globalErrorHandler;

Step 6: Wiring It All Together

Finally, you need to tell your Express app to use this handler. It must be the very last middleware you use, after all your routes.

// app.js

const globalErrorHandler = require('./controllers/errorController');

// ... your routes ...

app.use('/api/v1/users', userRouter);

// ... handle 404s for unknown routes ...

app.all('*', (req, res, next) => {

next(new AppError(`Can't find ${req.originalUrl} on this server!`, 404));

});

// GLOBAL ERROR HANDLER

app.use(globalErrorHandler);

The Result?

Imagine a user tries to sign up with an email that already exists.

Before: The user sees a spinning loader or a raw MongoDB error like E11000 duplicate key error collection.... They leave your site.
After (Production): The Global Handler catches code 11000, runs handleDuplicateFieldsDB, and sends back a crisp 400 Bad Request:

{

"status": "fail",

"message": "\"test@email.com\" already exists. Please use another value!"

}

Conclusion

Error handling isn't just about catching bugs; it's about User Experience (UX) and security.

By implementing catchAsync, AppError, and a centralized globalErrorHandler, you turn your backend into a fortress. You stop leaking stack traces to hackers, you give your users helpful feedback, and you keep your controllers clean and readable.

This is the difference between a side project and a professional API.

Further Reading

Express Error Handling Docs: https://expressjs.com/en/guide/error-handling.html
MongoDB Error Codes: https://www.mongodb.com/docs/manual/reference/error-codes/
JWT Best Practices: https://auth0.com/docs/secure/tokens/json-web-tokens