Bird
Raised Fist0
Node.jsframework~8 mins

Handling uncaught exceptions in Node.js - Performance & Optimization

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Performance: Handling uncaught exceptions
HIGH IMPACT
This affects the server's uptime and responsiveness by preventing crashes from unexpected errors.
Preventing server crash from unexpected errors
Node.js
process.on('uncaughtException', (err) => {
  console.error('Fatal error:', err);
  process.exit(1); // Exit to avoid unstable state
});
Exiting the process ensures the server restarts cleanly, avoiding memory leaks and inconsistent state.
📈 Performance GainPrevents memory bloat and keeps response times consistent by avoiding unstable server state.
Preventing server crash from unexpected errors
Node.js
process.on('uncaughtException', (err) => {
  console.log('Error:', err);
  // No process exit or recovery
});
Logging error without exiting or recovering can leave the server in an unstable state causing memory leaks or inconsistent behavior.
📉 Performance CostLeads to increased memory usage and potential slowdowns over time.
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Logging error without exitN/AN/AN/A[X] Bad
Logging error with process exitN/AN/AN/A[OK] Good
No cleanup on errorN/AN/AN/A[X] Bad
Graceful shutdown before exitN/AN/AN/A[OK] Good
Rendering Pipeline
Handling uncaught exceptions does not directly affect browser rendering but impacts server responsiveness and uptime, which indirectly affects user experience.
Server Runtime
Request Handling
⚠️ BottleneckServer crash or unstable state causing slow or failed responses
Optimization Tips
1Always exit the Node.js process after an uncaught exception to avoid unstable state.
2Perform graceful shutdown to free resources before exiting.
3Monitor logs and server responsiveness to catch uncaught exceptions early.
Performance Quiz - 3 Questions
Test your performance knowledge
What is the main performance risk of not exiting the Node.js process after an uncaught exception?
AThe browser will block rendering of the page.
BThe server will immediately restart automatically.
CThe server may become unstable and slow down over time.
DThe server will use less memory.
DevTools: Network and Console panels
How to check: Use Console to monitor uncaught exceptions logged. Use Network to check if server responses stop or delay after errors.
What to look for: Look for repeated error logs without server restart or slow/no responses indicating server instability.

Practice

(1/5)
1. What is the primary purpose of using process.on('uncaughtException') in a Node.js application?
easy
A. To handle HTTP requests automatically
B. To log user activity in the application
C. To restart the server after every request
D. To catch errors that were not handled anywhere else in the code

Solution

  1. Step 1: Understand the role of uncaught exceptions

    Uncaught exceptions are errors that happen but are not caught by any try-catch block or error handler in the code.
  2. Step 2: Purpose of process.on('uncaughtException')

    This event listener catches those uncaught errors to prevent the app from crashing unexpectedly.
  3. Final Answer:

    To catch errors that were not handled anywhere else in the code -> Option D
  4. Quick Check:

    Uncaught exceptions = catch unhandled errors [OK]
Hint: Remember: uncaughtException catches errors missed by try-catch [OK]
Common Mistakes:
  • Thinking it handles normal HTTP requests
  • Assuming it restarts the server automatically
  • Confusing it with logging user actions
2. Which of the following is the correct syntax to listen for uncaught exceptions in Node.js?
easy
A. process.listen('uncaughtException', (err) => { console.error(err); });
B. process.catch('uncaughtException', (err) => { console.error(err); });
C. process.on('uncaughtException', (err) => { console.error(err); });
D. process.handle('uncaughtException', (err) => { console.error(err); });

Solution

  1. Step 1: Identify the correct event listener method

    Node.js uses process.on to listen for events like 'uncaughtException'.
  2. Step 2: Verify the event name and callback

    The event name is exactly 'uncaughtException' and the callback receives the error object.
  3. Final Answer:

    process.on('uncaughtException', (err) => { console.error(err); }); -> Option C
  4. Quick Check:

    Use process.on for events [OK]
Hint: Use process.on for event listening, not catch or listen [OK]
Common Mistakes:
  • Using process.catch instead of process.on
  • Using process.listen or process.handle which don't exist
  • Misspelling the event name
3. Consider the following Node.js code snippet:
process.on('uncaughtException', (err) => {
  console.log('Caught:', err.message);
});

throw new Error('Oops!');

What will be the output when this code runs?
medium
A. The program crashes without any output
B. Caught: Oops!
C. Error: Oops!
D. No output, the error is ignored

Solution

  1. Step 1: Understand the uncaughtException handler

    The handler logs the error message prefixed with 'Caught:'.
  2. Step 2: The thrown error triggers the handler

    The thrown error 'Oops!' is caught by the listener and logged as 'Caught: Oops!'.
  3. Final Answer:

    Caught: Oops! -> Option B
  4. Quick Check:

    Uncaught error triggers handler output [OK]
Hint: Thrown error triggers uncaughtException handler output [OK]
Common Mistakes:
  • Expecting the program to crash immediately
  • Thinking the error message prints with 'Error:' prefix
  • Assuming no output because error is ignored
4. You wrote this code to catch uncaught exceptions:
process.on('uncaughtException', (error) => {
  console.log('Error:', error.message);
});

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

But the program crashes after the error is logged. What is the best fix?
medium
A. Add process.exit(1); inside the handler after logging
B. Remove the throw statement inside setTimeout
C. Wrap the throw inside a try-catch block
D. Use process.on('error') instead of uncaughtException

Solution

  1. Step 1: Understand uncaughtException behavior

    After catching, the app is in an unstable state and should exit safely.
  2. Step 2: Add process.exit(1) to stop the app

    Calling process.exit(1) after logging ensures the app stops cleanly.
  3. Final Answer:

    Add process.exit(1); inside the handler after logging -> Option A
  4. Quick Check:

    Exit after uncaughtException to avoid unstable state [OK]
Hint: Exit process after uncaughtException to avoid crashes [OK]
Common Mistakes:
  • Ignoring the need to exit after catching
  • Trying to catch error inside setTimeout instead
  • Using wrong event name 'error' instead of 'uncaughtException'
5. You want to log uncaught exceptions and then restart your Node.js server automatically. Which approach correctly combines handling uncaught exceptions and restarting the app?
hard
A. Use process.on('uncaughtException') to log error, then call process.exit(1), and use a separate script or tool to restart the server
B. Inside uncaughtException handler, just call server.listen() again to restart
C. Wrap the entire app code in a try-catch block to restart on error
D. Use process.on('exit') to catch errors and restart the server

Solution

  1. Step 1: Handle uncaught exceptions by logging and exiting

    Inside the handler, log the error and call process.exit(1) to stop the app safely.
  2. Step 2: Use an external tool or script to restart the server

    Node.js itself does not restart automatically; tools like PM2 or systemd can restart on exit.
  3. Final Answer:

    Use process.on('uncaughtException') to log error, then call process.exit(1), and use a separate script or tool to restart the server -> Option A
  4. Quick Check:

    Log + exit + external restart tool = correct approach [OK]
Hint: Exit on error, restart externally (PM2/systemd) for stability [OK]
Common Mistakes:
  • Trying to restart server inside uncaughtException handler
  • Using process.on('exit') to catch errors (wrong event)
  • Wrapping entire app in try-catch which misses async errors