How to catch and log errors in JavaScript

JavaScript’s error model revolves around the Error object and its various subclasses. When something goes wrong during execution, an error object is created and thrown, which can then be caught and handled. This throwing and catching mechanism is the foundation of how JavaScript deals with unexpected conditions.

All error objects inherit from the base Error type, which includes properties such as name and message. For example, if you try to access a property on undefined, a TypeError is thrown, a subclass of Error. Understanding these distinctions helps you target specific errors in your try...catch blocks.

Consider this example:

try {
  let obj = null;
  console.log(obj.property);
} catch (err) {
  console.log(err.name);    // "TypeError"
  console.log(err.message); // "Cannot read property 'property' of null"
}

Here, the runtime throws a TypeError because you tried to access a property on a null reference. The error object carries information about what went wrong, which you can inspect or log.

But errors are not limited to runtime exceptions. Syntactic errors, like missing parentheses or unexpected tokens, are detected by the JavaScript engine before execution and cannot be caught with try...catch. For instance, this code will never run:

try {
  eval('function () {'); // SyntaxError at parse time
} catch (err) {
  console.log('Won't catch this');
}

The key takeaway is that try...catch handles runtime errors only, not parse-time errors. This distinction is important when designing robust error handling strategies.

Another nuance is how asynchronous errors behave. If an error occurs inside a callback or a promise and you don’t handle it correctly, it might silently fail or cause unhandled promise rejections. For example:

setTimeout(() => {
  throw new Error('Oops!');
}, 1000);

This error is thrown asynchronously and won’t be caught by any outer try...catch block. The only way to handle such errors is through event listeners like window.onerror or promise rejection handlers.

Promises, introduced with ES6, have their own error propagation model. An error thrown inside a promise executor or a .then() callback will cause the promise to reject, which you can catch with .catch():

new Promise((resolve, reject) => {
  throw new Error('Failed!');
})
.then(() => {
  console.log('This won't run');
})
.catch(err => {
  console.log(err.message); // "Failed!"
});

Failing to handle promise rejections leads to unhandled rejection warnings in modern runtimes, which can cause your app to behave unpredictably or crash. This model encourages explicit handling of asynchronous errors, which is an improvement over older callback patterns.

It’s also worth noting that the throw statement in JavaScript doesn’t require an Error object. You can throw any value, though throwing objects derived from Error is best practice for consistent error information:

throw "Something went wrong";      // Allowed but discouraged
throw new Error("Something went wrong"); // Recommended

Throwing primitives or plain objects can make debugging and error tracking harder since stack traces and standard error properties are missing. Tools and IDEs typically expect error instances to provide meaningful context.

Finally, the finally clause in try...catch blocks always executes regardless of whether an error was thrown or caught. This is useful for cleanup operations:

try {
  // code that might throw
} catch (err) {
  // handle error
} finally {
  // cleanup code, runs every time
}

Understanding the subtleties of this error model lets you write handlers that are precise, avoid swallowing errors accidentally, and do not miss critical exceptions in either synchronous or asynchronous code paths. It’s the bedrock for building resilient JavaScript applications that behave predictably even when things go wrong.

Next, we’ll dig into practices that help prevent common pitfalls when handling these errors and patterns that keep your code maintainable and clear, but before that, remember that the JavaScript engine’s error model is not just about try...catch. Event-driven and asynchronous code demands you think beyond synchronous blocks and leverage promises, async/await, and global error handlers to cover all bases. Missing this means your error handling is incomplete and fragile.

For instance, consider an async function:

async function fetchData() {
  try {
    let response = await fetch('https://api.example.com/data');
    let data = await response.json();
    return data;
  } catch (err) {
    console.error('Fetch failed:', err);
  }
}

If you omit the try...catch here, any rejection in the fetch or JSON parsing will propagate to the caller, which might or might not handle it, leading to unhandled rejections. The async/await syntax is syntactic sugar over promises but does not change the fundamental error propagation rules.

These error propagation rules mean you have to decide where in your call stack to catch errors. Catching too early can obscure the original source of the error, while catching too late might leave your UI or application state inconsistent.

In conclusion, the JavaScript error model is straightforward in concept but intricate in practice. It requires a deliberate strategy that accounts for synchronous exceptions, asynchronous rejections, global error events, and the shape of the thrown errors themselves. Mastering this model is the first step toward writing code that doesn’t just break gracefully but recovers intelligently.

Moving forward, understanding how to apply these principles effectively involves not just catching errors but also deciding what to do with them once caught-whether to retry, log, wrap with additional context, or escalate them further up. This decision-making process is the heart of robust error handling.

Consider this enhanced example that wraps errors with context:

class FetchError extends Error {
  constructor(message, url) {
    super(message);
    this.name = 'FetchError';
    this.url = url;
  }
}

async function fetchWithErrorContext(url) {
  try {
    let response = await fetch(url);
    if (!response.ok) {
      throw new FetchError(Failed to fetch resource: ${response.status}, url);
    }
    return await response.json();
  } catch (err) {
    if (!(err instanceof FetchError)) {
      throw new FetchError(err.message, url);
    }
    throw err;
  }
}

This pattern helps maintain error semantics while adding valuable details, making debugging and logging much more effective. If you rely solely on generic errors, you lose context that often saves hours of troubleshooting.

As you build your error handling layers, keep in mind that the JavaScript runtime environment (browser, Node.js) also influences error behavior and available hooks. For instance, Node.js provides process.on('uncaughtException') and process.on('unhandledRejection'), while browsers have window.onerror and window.onunhandledrejection. These global handlers act as last-resort nets but should not replace targeted error handling.

To truly master the JavaScript error model, you must juggle all these aspects – synchronous exceptions, promise rejections, global handlers, and error object design – in a cohesive strategy that fits your application’s complexity and risk profile. Only then will your error handling be more than just a band-aid slapped on after errors occur.

Errors aren’t just an annoyance; they are signals, and decoding them properly is how you build systems that can diagnose and heal themselves. The next piece is about putting these insights into concrete best practices, starting with how to structure your try...catch blocks so they don’t become traps themselves,

Best practices for error handling

and how to implement logging that captures essential context without overwhelming your logs with noise. Effective logging is a critical part of error handling, as it allows you to trace issues back to their source and understand the state of your application when an error occurred.

When logging errors, always include relevant contextual information that can aid in diagnosing the problem. This might include the function name, parameters, and any state variables that are significant at the time of the error. Consider the following logging example:

function logError(err, context) {
  console.error({
    message: err.message,
    stack: err.stack,
    context: context,
  });
}

async function fetchData(url) {
  try {
    let response = await fetch(url);
    if (!response.ok) {
      throw new Error(HTTP error! status: ${response.status});
    }
    return await response.json();
  } catch (err) {
    logError(err, { url, timestamp: new Date() });
  }
}

This approach provides a structured log entry that can be easily parsed and searched through, which is invaluable when sifting through logs to identify issues. Using a logging library can enhance this further by allowing you to set log levels (e.g., debug, info, error) and control output formats.

Another important aspect is to avoid logging the same error multiple times, which can clutter your logs and make it difficult to identify new issues. Implementing a simple rate-limiting mechanism can help with this:

const errorLogLimit = new Map();

function logErrorWithLimit(err, context) {
  const key = ${err.message}-${context.url};
  const now = Date.now();
  const limit = 10000; // 10 seconds

  if (!errorLogLimit.has(key) || (now - errorLogLimit.get(key) > limit)) {
    errorLogLimit.set(key, now);
    logError(err, context);
  }
}

This function prevents excessive logging of the same error within a defined time frame, allowing you to focus on unique issues without drowning in repetitive log entries.

In addition to logging, consider how to propagate errors through your application. You may want to wrap errors in custom error types that carry additional information about the context in which they occurred. This can make it easier to handle errors at different levels of your application:

class CustomError extends Error {
  constructor(message, details) {
    super(message);
    this.details = details;
    this.name = this.constructor.name;
  }
}

async function processRequest(req) {
  try {
    // Some processing logic
  } catch (err) {
    throw new CustomError('Request processing failed', { requestId: req.id, originalError: err });
  }
}

This pattern allows you to create a hierarchy of error types, making it easier to catch and handle specific errors at higher levels of your application. It also provides a clear structure for passing additional context along with the error, which can be crucial for debugging.

As you refine your error handling practices, remember that the goal is not just to catch errors but also to respond to them appropriately. This might mean retrying a request, alerting users, or even shutting down a service gracefully. Each response should be tailored to the specific error and the context in which it occurred.

Effective error handling in JavaScript encompasses not only the mechanics of catching and logging errors but also the thoughtful design of error types and propagation strategies. These practices help ensure that your application is robust, maintainable, and capable of providing meaningful feedback when things go wrong. The next step will explore advanced techniques for tracking and analyzing error trends over time, allowing you to proactively address issues before they escalate into major problems.

Techniques for logging errors effectively

Effective logging is not just about capturing errors; it’s about capturing them in a way that provides insight into the state of your application at the time of the error. This means that your logging should include not only the error message and stack trace but also contextual information that can help you understand what was happening in your application when the error occurred.

To enhance your logging strategy, consider creating a structured logging format. This could include details such as user IDs, request paths, or any relevant application state. Here’s an example of how to implement such structured logging:

function logError(err, context) {
  const logEntry = {
    timestamp: new Date().toISOString(),
    message: err.message,
    stack: err.stack,
    context: context,
  };
  console.error(JSON.stringify(logEntry));
}

This format allows for easier parsing and searching of logs, making it simpler to identify issues when they arise. Additionally, consider using a logging library that provides features like log levels and external log management services, which can help centralize and analyze your logs.

Another key technique is to categorize your errors based on severity. Not all errors are equal; some may require immediate attention while others might just be informational. Implementing a severity level within your logging function can help prioritize responses:

function logErrorWithSeverity(err, context, severity = 'error') {
  const logEntry = {
    timestamp: new Date().toISOString(),
    message: err.message,
    stack: err.stack,
    context: context,
    severity: severity,
  };
  console[severity](JSON.stringify(logEntry));
}

This allows you to log warnings, info, and errors appropriately, making it easier to filter logs based on urgency. For example, you might want to send error logs to a monitoring service while only logging warnings locally.

Another effective technique is to implement a global error handler that captures uncaught exceptions and unhandled promise rejections. This ensures that any errors that slip through the cracks are still logged, providing a safety net for your application:

window.addEventListener('error', (event) => {
  logError(event.error, { source: 'window.onerror' });
});

window.addEventListener('unhandledrejection', (event) => {
  logError(event.reason, { source: 'promise rejection' });
});

By utilizing these global handlers, you can ensure that your application remains resilient, even in the face of unexpected errors. This approach also allows you to maintain a single logging strategy across your application.

When it comes to error logging, also consider the implications of performance. Excessive logging can slow down your application, especially in high-traffic scenarios. Implementing a sampling strategy, where you log only a subset of errors, can help mitigate this issue:

const logSamplingRate = 0.1; // Log 10% of errors

function logErrorWithSampling(err, context) {
  if (Math.random() < logSamplingRate) {
    logError(err, context);
  }
}

This strategy balances the need for visibility with the performance considerations, allowing you to capture enough data to be useful without overwhelming your system.

Finally, consider integrating your logging with monitoring and alerting systems. This ensures that when critical errors occur, they trigger alerts to the development team, allowing for rapid response. For example:

function notifyTeam(err) {
  // Send error details to a monitoring service
}

function logErrorWithAlert(err, context) {
  logError(err, context);
  if (err.severity === 'error') {
    notifyTeam(err);
  }
}

This approach provides a proactive way to address issues before they escalate, ensuring that your application remains stable and user-friendly. By implementing these techniques, you can create a robust error logging strategy that not only captures errors but also provides valuable insights into your application’s behavior.