Handling uncaught exceptions in Node.js - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What happens when an uncaught exception occurs in Node.js?

Consider a Node.js application without any error handling for exceptions. What is the typical behavior when an uncaught exception occurs?

A Node.js automatically retries the failed operation causing the exception.

B The exception is silently ignored and the process continues running.

C The Node.js process immediately exits with a non-zero exit code.

D The exception is logged but the process keeps running without interruption.

💡 Hint

Think about what happens if an error is not caught anywhere in the code.

When an uncaught exception occurs, Node.js by default prints the error stack trace and then exits the process with a non-zero exit code to avoid running in an unstable state.

❓ component_behavior

intermediate

What is the output of this Node.js code handling uncaught exceptions?

Analyze the following Node.js code snippet and select the correct console output.

Node.js

process.on('uncaughtException', (err) => {
  console.log('Caught exception:', err.message);
});

throw new Error('Test error');
console.log('This line will run');

A Caught exception: Test error

B

Caught exception: Test error
This line will run

C

This line will run
Caught exception: Test error

D No output, process crashes silently

💡 Hint

Consider what happens after an uncaught exception is thrown and caught by the handler.

The uncaughtException handler logs the error message. However, after an uncaught exception is thrown, the process does not continue normal execution, so the next line does not run.

🔧 Debug

advanced

Identify the error in this uncaught exception handler code

Find the mistake in this Node.js code that tries to handle uncaught exceptions.

Node.js

process.on('uncaughtException', (error) => {
  console.error('Error caught:', error);
  process.exit(1);
});

setTimeout(() => {
  throw new Error('Failure');
}, 100);

console.log('App started');

A The error parameter should be named err, otherwise it won't catch the exception.

B The handler calls process.exit(1) which stops the process immediately, so asynchronous cleanup code won't run.

C The setTimeout callback should be synchronous to catch the error properly.

D The console.log('App started') will never run because the exception is thrown.

💡 Hint

Think about what happens when process.exit is called inside the handler.

Calling process.exit(1) immediately stops the Node.js process, so any asynchronous cleanup or logging after that call will not execute. This can cause resource leaks or incomplete shutdown.

📝 Syntax

advanced

Which option correctly attaches an uncaught exception handler in Node.js?

Select the code snippet that correctly listens for uncaught exceptions.

A process.on('uncaughtException', (err) => { console.log(err.message); });

B process.catch('uncaughtException', (err) => { console.log(err); });

C process.addListener('uncaughtException', function errorHandler() { console.log('Error'); });

D process.handle('uncaughtException', (error) => { console.error(error); });

💡 Hint

Recall the correct method name to listen to events on the process object.

The correct method to listen for events on the process object is process.on. Options A and D use invalid methods. Option A uses a valid method name but the function signature is missing the error parameter, so it won't receive the error object.

❓ lifecycle

expert

What is the best practice for handling uncaught exceptions in a production Node.js app?

Choose the most appropriate approach to handle uncaught exceptions in a production environment.

A Catch all exceptions globally and retry the failed operation automatically.

B Ignore the exception and let the process continue running to avoid downtime.

C Use <code>process.exit(0)</code> inside the handler to restart the process silently.

D Log the error, perform any synchronous cleanup, then gracefully shut down the process.

💡 Hint

Think about stability and data integrity when an unexpected error occurs.

In production, the best practice is to log the error, perform any necessary synchronous cleanup (like closing database connections), and then gracefully shut down the process. This avoids running in an unstable state and allows external tools to restart the app.