With anyone in the world throwing requests at our program, it’s only a matter of time before values get into our program that we didn’t expect. You have users who are sending requests for data from your server. Imagine you’re using Node.js to build a RESTful web API. Node.JS Error Handling: Why Bother?įirst let’s address the big question: why bother handling errors at all? Then, we’ll discuss best practices and common stumbling blocks that developers often struggle with when dealing with Node.js error handling. Today we’re going to take you through the above items and give you a tour of JavaScript’s main quirks for better insight and understanding. We can, however, avoid issues by preparing our code to properly handle errors. When deploying applications into production, we want to know that all code has been tested for all possible complex scenarios. For example, looking at part of the code from on of my oldest native addons which worked for the v0.8.x Node.js versions: #include ' error handling isn’t a walk in the park. Backgroundīack in the old Node.js days the only way to implement a Node.js native addon was by using v8, Node.js and libuv libraries. So when thinking on a topic for a blog, it struck me that writing about the migration of a couple of my addons from using NAN to Node-API could be interesting. The years passed and Node-API was created and though it was on my radar and saw the benefits of using it, I never had the time to try it on my own modules. When NAN was created which made life much easier, especially in terms of maintenance, there was no question that I should move all my addons to use it.

The first ones were created by using the native C++ Node.js and v8 API’s.

Throughout the years I’ve created my fair share of native addons.

Node api