This article is for JavaScript and NodeJS developers who want to improve error-handling in their applications. Kelvin Omereshone explains the error class pattern and how to use it for a better, more efficient way of handling errors across your applications.

Error handling is one of those parts of software development that don’t quite get the amount of attention it really deserves. However, building robust applications requires dealing with errors properly.

You can get by in NodeJS without properly handling errors but due to the asynchronous nature of NodeJS, improper handling or errors can cause you pain soon enough — especially when debugging applications.

Before we proceed, I would like to point out the type of errors we’ll be discussing how to utilize error classes.

Operational Errors

These are errors discovered during the run time of a program. Operational errors are not bugs and can occur from time to time mostly because of one or a combination of several external factors like a database server timing out or a user deciding to make an attempt on SQL injection by entering SQL queries in an input field.

Below are more examples of operational errors:

• Failed to connect to a database server;
• Invalid inputs by the user (server responds with a 400 response code);
• Request timeout;
• Resource not found (server responds with a 404 response code);
• Server returns with a 500 response.

It’s also worthy of note to briefly discuss the counterpart of Operational Errors.

Programmer Errors

These are bugs in the program which can be resolved by changing the code. These types of errors can not be handled because they occur as a result of the code being broken. Example of these errors are:

• Trying to read a property on an object that is not defined.

 const user = {
   firstName: 'Kelvin',
   lastName: 'Omereshone',
 }

 console.log(user.fullName) // throws 'undefined' because the property fullName is not defined

• Invoking or calling an asynchronous function without a callback.
• Passing a string where a number was expected.

This article is about Operational Error handling in NodeJS. Error handling in NodeJS is significantly different from error handling in other languages. This is due to the asynchronous nature of JavaScript and the openness of JavaScript with errors. Let me explain:

In JavaScript, instances of the error class is not the only thing you can throw. You can literally throw any data type this openness is not allowed by other languages.

For example, a JavaScript developer may decide to throw in a number instead of an error object instance, like so:

// bad
throw 'Whoops :)';

// good
throw new Error('Whoops :)')

You might not see the problem in throwing other data types, but doing so will result in a harder time debugging because you won’t get a stack trace and other properties that the Error object exposes which are needed for debugging.

Let’s look at some incorrect patterns in error handling, before taking a look at the Error class pattern and how it is a much better way for error handling in NodeJS.

#node #javascript #developer