Node.js process/env and Error Handling Patterns

1. Error-first callback convention

• Legacy callbacks in Node (fs.readFile, legacy DB drivers...) always place the error argument as the first parameter: (err, data) => {...}.
• Core reason: placing err at a fixed first position establishes a unified pattern that enables "fail fast": if (err) return callback(err), applicable across all asynchronous functions in the Node ecosystem without needing to remember different parameter positions per function.
• JavaScript does not automatically throw errors or warn if you forget to check err; the code continues running normally, which easily leads to hard-to-debug issues far away from where they originated. Use ESLint (rules such as handle-callback-err) to prevent forgetting this check.
• Drawback: when multiple asynchronous operations run sequentially, this pattern causes callback hell (deeply nested layers, difficult to read).

2. Promise and async/await

• Promise .then().then().catch() solves callback hell but can still create "promise chain hell" if the chain grows too long.
• async/await combined with try/catch solves both problems: code reads sequentially and naturally like synchronous code, and consolidates errors from multiple consecutive await steps into a single catch block:

async function main() {
  try {
    const user = await getUser(id);
    const orders = await getOrders(user.id);
    const details = await getOrderDetails(orders[0].id);
  } catch (err) {
    console.error(err);
  }
}

• If any await line inside throws an error, execution jumps directly to catch, equivalent to a .catch() at the end of a Promise chain but much more natural to read.

3. Unhandled Promise rejection

• If a Promise is rejected without a .catch() or without being wrapped in try/catch, Node does not silently swallow the error; instead, it outputs an UnhandledPromiseRejectionWarning.
• From Node 15 onwards (the current default): an unhandled rejection causes the process to crash entirely, treated as a severe error equivalent to an uncaught exception. Prior to Node 15, it only printed a warning and continued running.
• Reason Node switched to crashing entirely: if it only warns and continues running, each unhandled rejected Promise retains its reference in memory (in case a .catch() is attached later). Repeating this continuously leads to a memory leak; RAM is gradually occupied without being freed, causing the server to run for a few days before crashing unexpectedly due to running out of RAM, making it very difficult to trace the root cause.
• Crashing immediately (fail fast) exposes bugs early during dev/test, rather than silently causing prolonged memory leaks in production.
• Prevention: always include .catch() or try/catch for every Promise; you can also listen to process.on('unhandledRejection', ...) at the top level to log before crashing.

4. process.env and environment variables

• process.env is an object containing all environment variables. It is used to store sensitive values (DB connection strings, API keys, secrets) instead of hardcoding them, preventing exposure when pushing code to git, and allowing each environment (dev/staging/production) to use different values without modifying code.
• Node does not automatically read .env files and load them into process.env. By default, it only reads environment variables that already exist at the OS level (set via the terminal prior to execution).
• The dotenv library reads the .env file, parses its contents (KEY=value), and manually assigns each pair to process.env, typically invoked via require('dotenv').config().
• dotenv.config() must be called on the very first line of the entry point file, before any other imports. If called late (e.g. at the bottom of the file), other modules imported earlier that read process.env immediately upon load (like a DB connection file) will receive undefined, causing connection failures even if .env has the correct data.
• Do not commit the actual .env file to git (add it to .gitignore). Use .env.example listing the required variable names (without actual values) to commit to git, helping other team members know what needs to be configured.