Robust Node.js applications need a clear strategy for handling errors, which can occur at multiple levels. Synchronous errors and those thrown inside async functions can be caught with try/catch. Callback-based APIs follow the error-first callback pattern, where the first argument to the callback is an Error object (or null if successful) and should always be checked before using the result. Promises expose errors through .catch(), and event-based APIs like streams emit an 'error' event that must be handled to avoid crashes.
For errors that escape all other handling, Node.js provides last-resort hooks: process.on('uncaughtException') catches synchronous errors that bubble all the way up, and process.on('unhandledRejection') catches Promise rejections without a .catch() handler. The recommended practice for both is to log the error, clean up any critical resources, and exit the process; attempting to keep running after an uncaught exception can leave the application in an undefined state. Building a solid error-handling strategy means combining all these layers appropriately for each kind of failure.
Underpinning much of Node.js is the EventEmitter class, the heart of its event-driven architecture. You create an instance with new EventEmitter(), register listeners with on() (or fire-once with once()), trigger events with emit(), and remove listeners with removeListener(). Many core modules, including streams, the http server, and process itself, inherit from EventEmitter, so understanding its pattern unlocks a great deal of Node.js behavior.
The global object in Node.js, named global (analogous to window in browsers), exposes several utilities. CommonJS modules can use __dirname and __filename to access the current file's path. The process object gives access to environment variables (process.env), command-line arguments (process.argv), the current working directory (process.cwd()), the process ID (process.pid), and memory statistics (process.memoryUsage()). It also allows graceful termination with process.exit(code) and handling of OS signals through process.on('signal', handler). Together, these facilities provide the runtime introspection and control needed to build reliable, well-behaved server applications.